Using a repository's code as a starting point

[Ashley Mosuro]

Being fairly new to GIT, I'm trying to understand the best way to approach this situation:

Situation:

• I have a repository set up which contains a 'boilerplate' website I have built (let's call it the boilerplate repository)
• I use this boilerplate repository as the starting point for all of my projects
• All of my projects must have their own repository, so they're not set up under the boilerplate repository

How I currently work:

• At the moment I'm setting up a new repository for my new project (e.g. exampleproject repository)
• Copying all of the files inside my boilerplate repository's working copy
• Pasting them into my exampleproject repository's working copy
• Then pushing them up to the exampeproject repository

Problem:

• It feels like there should be a better way to simply copy (clone?) a repository's code into another empty repository, so that you can use it as the starting point.
• I'm familar with git fetch and it sounds like that command may be what I'm looking for, but I'm hoping somebody can clarify and suggest best the practice.

I'm using Source Tree to manage my repositories, along with Beanstalk.

[Aseem Parikh · Accepted solution]

I'm not familiar with Beanstalk, but GitHub and Bitbucket both have a "fork" feature which allows you to spawn a new repository from a common ancestor. Forking is essentially the same as cloning with a couple extra steps:

1. A brand new repository (exampleproject repository) is created based on the parent (boilerplate repository).
2. A new remote repository is added to the new repo to specify the parent project.

This github article explains the process quite nicely.

In your case, the fact that code changes can still be pulled from the parent repo would be one of the primary benefits of forking. For example, if you reference jquery in your boilerplate repo and you want to update it to the latest version in all repos, you only need to make the change in your boilerplate repo. You'll then need to fetch and merge the changes into the other repos.

Note: forking should not be confused with spooning.

[tlroche]

Ashley Mosuro
> Surely having all of my websites under one repository will cause speed performance issues when working with version control?

"Surely" you know something about the domain in question :-) such as "What a Branch Is"

http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is
> Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots.

> When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.

> [Example with diagrams follows in original.]

> A branch in Git is simply a lightweight movable pointer to one of these commits.

> [More diagrams.]

> What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing.

> [Example with diagrams follows, that you should read before pronouncing on performance issues :-]

> Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).

[Ashley Mosuro]

Thanks for the clarification Tom, wasn't completely aware of the performance side of using Git branches, so that was very useful info.

Unfortunately I think I'm going to be somewhat limited to using repositories for each website, simply because I'm using Beanstalk and there are restrictions on the number of deployment servers you can use per repository, which obviously causes problems if the majority of my clients have their own hosting solutions - I'll very quickly reach that deployment server limit and have to create a new repository to get more.

[tlroche]

> Ashley Mosuro
> * I use this boilerplate repository as the starting point for all of my projects
> * All of my projects must have their own repository, so they're not set up under the boilerplate repository

Instead of separate repositories, why not separate branches? That would be the more `git`-ish way (see link above to "the git book," an excellent free reference). You would then, e.g., maintain a branch with name=`boilerplate` (merging in desired improvements as desired). When you want to create a new project name=`example`, you would

1. `git checkout boilerplate`
2. `git checkout -b example` to create and switch to branch name=`example`

You would then work in branch=`example`, committing and pushing as desired, and merging to other branches as desired.

[Ashley Mosuro]

Surely having all of my websites under one repository will cause speed performance issues when working with version control? I mean, let's say I have 100 websites on branches under one repository...is there any downside to this?

And in regards to deployment, are there any restrictions to having multiple websites under one repository? I would need to specify a branch, and what server to push that branch's content to.

It's definitely an option but I just want to be sure it's the best way before commiting to having all my sites under one repository.

[KieranA]

Just as some input, you really shouldn't put different websites into different branches. That isn't what branches are for, they're for diverging code used for features/bugs until you merge them back into your main stream of development. You can keep all your websites under one repository, but not in separate branches.

Will it be slow? That depends on how many commits you've got perhaps, but generally Git is very fast. With 100 websites, have you got 30,000+ commits? That's how many commits the Git repo itself has. Recently we had a user present us with his company repo which had over 100,000 commits in it. So if each website had a thousand commits then you'd be matching that, which would be large.

It all depends on your current repositories.

[Ashley Mosuro]

Okay, interesting...so it's okay to keep different websites under one repository, but not to separate them using branches?

I'm curious to know how you differentiate/track the changes to each site then, because from a management point of view it must be quite tricky to know exactly what needs committing when you have a ton of commits coming from various different websites. Then there's the deployment side of things, and how you push changes live to a site without pushing changes for another site.

I suspect this all depends on our specific workflow setups, so not necessarily looking for a solution, it's just interesting to know how others are managing their version control.