I have some software application managed using Git. I just released a new version 2.x which I plan to maintain on the long term (bug fixes mostly). In the meantime, I would like to start working on version 3.x. What is the recommended way to manage this? Should I create a branch for version 2.x and have the 3.x development on the master? or the other way?

  • Have a different branches for development and stable.
    – Oded
    Dec 23, 2011 at 9:51
  • So what usually goes into the master branch? (up until now I always do everything there)
    – laurent
    Dec 23, 2011 at 9:53
  • You need to decide what you want master to mean. It is just a label.
    – Oded
    Dec 23, 2011 at 9:56

3 Answers 3


A very interesting way of doing things was described here: A successful Git branching model

I found it very intriguing, but have yet to actually use it.

Very well, as requested a (very) short summation of what the article says:

  • The Master branch only every represents finished milestones (i.e. Version 1.0, 1.1, 1.2 etc.)
  • Development is done in it's own branch (conveniently named "develop", who'd have thought?). The develop branch is merged back into the the Master branch, whenever a feature complete version is done.
  • Branching off from development are feature branches. These represent single features for the next (or any future) release. They merge back with the develop branch.
  • Another branch coming from development is the "release" branch. This is a branch that represents an almost complete release version where only minor details have to be cleaned up. It merges with the development branch and ultimately with the Master branch
  • "Hotfix" branches branch of from the master branch if you find a severe bug in one of your releases (i.e. "If the use enters the konami code our program will reformat the main harddrive..."). It branches of from the buggy release and, when the fix is finished is merged back into the master branch AND the devlopment branch.

That's the short of it, but trust me, that the article describes it in way more detail, and with the helpfull visualisation graphic it is much easier to understand.

  • 2
    You should include some explanation on your suggestion in the answer, preferably people will not have to follow the link to get an overall idea of the model. Links have the bad habit of going awol, and answers should stand on their own...
    – yannis
    Dec 23, 2011 at 10:28
  • +1 Pretty much what we use at work, and it really does work.
    – Ed James
    Dec 23, 2011 at 10:53
  • 1
    I believe this is commonly referred to as the "stable trunk" or "feature branch" model.
    – sleske
    Dec 23, 2011 at 14:36
  • "The Master branch only every represents finished milestones (i.e. Version 1.0, 1.1, 1.2 etc.)" I would not want a master branch with versions 1.0, 1.1, 1.2, 2.0, 1.3, 2.1, 1.4, 2.2, 3.0, 1.5 in that order, that would be really confusing. My guess is that there is an implicit assumption that there is at most one stream on which releases are done, that's not the case in my practice. There are early adopters and people wanting something more stable. Dec 23, 2011 at 17:20
  • Well, in the long run a branch is nothing more then a label to make it easier for you to know whats happening there. So if you don't like it this way, there is nothing stopping you from using the Master branch for only mayor stable releases and having an "Trial" Branch (or whatever you want to call it) for smaller incremental releases.
    – Sorcy
    Dec 25, 2011 at 19:38

My principle is that the more short term the branch is, the deeper it should be in the branch structure and the more specific its name will be. The longer term the branch is, shallower it will be in the branch structure and more generic its name will be.

So you keep your master for the longer term (3.X) version and you keep naming this branch with a generic name (master, trunk, devel, ...) and not a specific one (release code name or even worse release numbers which are too much dependend in practice on late marketting decision)

It does not matter so much in a system like git which has a flat name space for branches and where branches are equivalent. It matters more with a system like clearcase which has a hierarchical namespace for branches (the full name of the V4 branch end up beeing main/v1/v2/v3/v4...)

  • +1 except I don't know what deep and shallow really means in this context, perhaps you could expand on those terms a little? Apr 14, 2015 at 11:55
  • Thinks of branches making a tree. They may come out the trunk or another branch. Shallow means that the number of branching step between the branch and the trunk is small, deep means that the number of branching step is important. What small and important is is mostly relative, but I've seen schemes for which each new releases was a step further than the previous one from the trunk. If you are using a flat namespace, that's not so bad. If the namespace is hierarchical (clearcase, CVS, RCS, Perforce can be used in such a way as well), you get longer and longer names. Apr 14, 2015 at 12:34

The main branch continues as usual while you make a release branch for anything that needs to be fixed on the release branch.

* bb1ce71 (HEAD -> main) Feature A (Wraparound)
* 024dc71 Feature Z
* d46cc00 (release-1.0) Version 1.0
* 336a765 Feature Y
* ceb05a7 Feature X
* 6c0468f Init

This branch could also be checked out when you need it instead of ahead of time, since you won’t need the branch until you have something that you need to fix on it.

Say you need a hotfix for X:

* 45117fc (HEAD -> release-1.0) Fix bug in X
| * fea9e06 (main) Feature B
| * bb1ce71 Feature A (Wraparound)
| * 024dc71 Feature Z
* d46cc00 Version 1.0
* 336a765 Feature Y
* ceb05a7 Feature X
* 6c0468f Init

main also needs that bug fix. So you merge the release branch into it.

# Note: `main`-only view
* 7f9ff9a (HEAD -> main) Merge branch 'release-1.0' (Hotfix for X)
* fea9e06 Feature B
* bb1ce71 Feature A (Wraparound)
* 024dc71 Feature Z
* d46cc00 Version 1.0
* 336a765 Feature Y
* ceb05a7 Feature X
* 6c0468f Init

And so it goes until you stop supporting that release, at which point you will probably delete the release branch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.