Branching Strategies in Git – Overview
February 18th, 2009Creating a branch in Git is simple:
$ git branch new_branch
That’s all that’s absolutely required (see the man page for all the options). And with that you now have a new branch to work on whose starting point is where you just were in your Git repository.
So what can you do with it? Or more to the point, what should you do with it?
For a single developer, you can work on an experimental code path: You’ve got an idea about how a feature should be implemented and want to get started. But you’ve also got some regular development that needs to take place at the same time (fixes, other features, etc.). So create a branch and code away:
$ git branch feature_x dev
$ git checkout feature_x
# add/commit... add/commit... add/commit
If the feature code works out, you merge it back into your development branch.
$ git checkout dev
$ git merge feature_x
If not, you just go back to the dev branch and delete feature_x:
$ git checkout dev
$ git branch -D feature_x
Actually, you really don’t have to delete the branch. You can leave it as is in case you want to easily go back to take a look at that work.
For a team, branches separate each developer’s individual updates. The distributed nature of Git sets up a default branch structure: Each repository creates a new branch in the extended repository network.
For a set of repositories configured as
the extended branch structure would look like
From your local repository, you’ll be limited to seeing only the branches on the remotes you’re connected to.
For Alice who’s connected to shared and Bob, the branches that her repository knows about are
alpha:alice $ git branch -a
dev
bob/dev
shared/dev
For Bob who’s connected to shared and Alice,
beta:bob $ git branch -a
dev
alice/dev
shared/dev
And for Chris,
gamma:chris $ git branch -a
dev
shared/dev
For a project, a branch could represent a new feature set or version of an application. Updates are pushed up to an “integration” branch by developers as they are completed. This is similar to the use of branching by a single developer but on a more formalized, process-driven basis.
In this case, Alice has already merged her changes for Project A into the shared integration branch. Bob and Chris are still working on their changes and will need to pull in the updates before they’ll be able to push up to shared/integration.
Branches can also be used to represent the application’s lifecycle, with separate branches for each state such as development, test, and production.
This is the ideal case where changes flow from development to test and then from test to production.
These strategies are, of course, only a starting point. Your actual branching structure will depend on your team and where you are in your application development cycle. And odds are it’ll evolve along the way.
We’ll be going into more detail in future posts.
March 24th, 2009 at 4:15 am
Branches are beautifully explained in this article. I bookmark it for future explainations.
But I don’t like the last diagram. Reading it, we can feel that development branch is based on test branch which is based, in turn, onto production branch. IMHO, development come first, then we branch to fix code, and finally we branch to keep track of production state.
Related to branches, here is a really good article presenting “customers” branches: titled “Never merging back”, http://gitster.livejournal.com/26540.html
March 24th, 2009 at 9:05 pm
@Guyou-
No matter which way you start (development first or production “first”), you’ll end up with a similar looking branch diagram.
The test and production branch head pointers will always trail development. I’ve put in the “kinks” at the start of test-level and dev-level commits are located to help indicate the lifecycle state. Otherwise it would be a straight line of commits in this ideal case. Since no changes are made directly against the production and test branches, any merges from development to test and from test to production are fast-forwards.
Probably what you’re visualizing is when changes from development are added by cherry-picking onto test (and likewise from test to production). In that case you would have truly separate test and production branches that do start from along the development branch.
April 11th, 2009 at 3:38 pm
What tool is generating those branch diagrams?
April 19th, 2009 at 7:30 am
[...] http://gitguru.com/2009/02/18/branching-strategies-overview/ – Good description of GIT branching (or branching in general); I’m more used to back mergeing then forward merging. This seems to just merge to the trunck where the trunk is at. Posted in Computers | Leave a Comment [...]
June 23rd, 2009 at 3:50 am
[...] git branching explained: http://gitguru.com/2009/02/18/branching-strategies-overview/ [...]
December 9th, 2010 at 8:15 am
@George
Looks like dia to me.
January 10th, 2011 at 5:34 am
i would have been delighted by the set of commands that are used in the start of the team-part of this article, what would every user of the `central` repository type in his or her machine in order to get the set-up that is used in the article?
how will they come to know each other’s branches? how can they merge changes of each other? how will they commit their changes or leave a set of changes behind?
i’d like to thank you for this quite well written text,
it’s quite complete besides the questions i’ve put forward,
i like that it tells in a compact and understandable way what the different steps are and that it provides the command you wll need to type in a clear way.
May 14th, 2011 at 11:04 am
[...] gitguru » Branching Strategies in Git – Overview [...]
September 8th, 2011 at 3:34 pm
[...] gitguru » Branching Strategies in Git – Overview (tags: git branching) [...]
September 14th, 2011 at 11:37 am
You should point out that your graphs will never look like what you have for the first one, unless your merging with non-fast-words, other than that its good.
November 10th, 2011 at 7:13 am
[...] Branch: Words fall short when trying to explain branches. They are exactly as they sound in real life, with the exception that branches can be merged together again. An excellent example along with diagrams is available at gitguru. [...]