Branching Strategies in Git – Overview

February 18th, 2009

Creating 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

Feature branch created off dev branch

If the feature code works out, you merge it back into your development branch.

$ git checkout dev
$ git merge feature_x

Feature branch merged into dev branch

If not, you just go back to the dev branch and delete feature_x:

$ git checkout dev
$ git branch -D feature_x

Feature branch left unmerged

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

Team repositories

the extended branch structure would look like

Team branches

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.

Project integration

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.

Lifecycle via branches

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.

11 responses

  1. Guyou comments:

    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

  2. long comments:

    @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.

  3. George V. Reilly comments:

    What tool is generating those branch diagrams?

  4. codeAPE » Blog Archive » Mercurial for subversion users pings back:

    [...] 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 [...]

  5. adrians's status on Tuesday, 23-Jun-09 11:50:39 UTC - Identi.ca pings back:

    [...] git branching explained: http://gitguru.com/2009/02/18/branching-strategies-overview/ [...]

  6. leif81 comments:

    @George

    Looks like dia to me.

  7. immeëmosol comments:

    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.

  8. ems help comments:

    [...] gitguru » Branching Strategies in Git – Overview [...]

  9. Buzz Lightyear is here » Blog Archive » links for 2011-09-08 pings back:

    [...] gitguru » Branching Strategies in Git – Overview (tags: git branching) [...]

  10. zane matthew comments:

    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. :D

  11. Terminology « Rural Ramblings pings back:

    [...] 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. [...]

Leave a comment