5.4. Git branching model

5.4.1. Background theory

If you don’t want to read all this theory, you can skip straight to the next section.

Our branching model is based on Vincent Driessen’s article A successful Git branching model (published Jan 2010).

The original article did not adequately handle concurrent support for multiple releases, but the following extracts from comments to the article do:

  • Rory Fitzpatrick:

    Not sure what software you're releasing, but I'm wondering how you would handle hotfixing a previous release that you still had to support?
    i.e. you've just released 2.0 but have to hotfix 1.0 for a customer, where does the hotfix-1.0.1 branch get merged into and ultimately tagged for release?

    Vincent Driessen in reply to Rory Fitzpatrick:

    @Rory: That's an excellent follow-up question. To be honest, I haven't thought about that scenario consciously.
    But say you have the following situation:
    * You have tagged your releases 1.0, 1.1 and 2.0.
    * 1.x and 2.x are sold under different licenses.
    * Some critical bug must be fixed in both the 1.x and 2.x versions, and you do not want your customers to be forced to upgrade to 2.x
    My solution to that would be the following:
    * Create a "support branch" called support-1.x, based on tag 1.1 (since that is the latest 1.x commit).
      This branch should be long-lived and can be safely removed if you drop support on 1.x.
    * Create a branch hotfix-1.1.1, based on support-1.x
    * Create a branch hotfix-2.0.1, based on 2.0
    * Fix the bug on each (git cherry-pick may help here)
    Then, finish hotfix-1.1.1 by merging back into support-1.x (don't forget --no-ff), so not into master or develop.
    Technically you could just merge back those changes into develop, but the commit graph would quickly become like a plate of spaghetti.
    Rather leave these situations to git cherry-pick (personal taste).
    You can finish hotfix-2.0.1 as you would regularly (merge back into master or develop).
    Merging the fix into develop causes the bug be fixed in all future releases.
    Effectively, what you're doing then, is having a master branch per supported product release.
    Maybe I'm forgetting something, haven't thought about it too long yet. Very interesting addition to the article!
  • Joe:

    Acutally I think a more classical way of supporting the "in the wild" releases is to keep the release branch
    (instead of deleting after it is merged back to develop). You would have (for example) release 1.2.x on one release branch
    with subsequent releases 1.2.1, 1.2.2, etc. delivered from this branch and with bug fixes merged back to the develop branch.
    You would delete the release branch when you stop supporting a release (but this is optional (you may want to keep the branch alive even if is dormant).

The following discussions of the branching model may be of interest:

5.4.2. Supporting software

A collection of Git extensions (git-flow) to provide the high-level repository operations for the branching model has been developed, and is available at github. The scripts can handle so-called support branches as described in the previous section.

Although use of git-flow is not compulsory (you can always issue the native git commands), it simplifies the workflow and reduces the chance of error.

5.4.3. Other Git considerations

What is the git equivalent for revision number? (stackoverflow, Nov 2010)