Take the 2-minute tour ×

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?

share|improve this question
Have a different branches for development and stable. –  Oded Dec 23 '11 at 9:51
So what usually goes into the master branch? (up until now I always do everything there) –  this.lau_ Dec 23 '11 at 9:53
You need to decide what you want master to mean. It is just a label. –  Oded Dec 23 '11 at 9:56
add comment

2 Answers

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.

share|improve this answer
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 Rizos Dec 23 '11 at 10:28
+1 Good answer and amazing edit. –  Yannis Rizos Dec 23 '11 at 10:50
+1 Pretty much what we use at work, and it really does work. –  Ed Woodcock Dec 23 '11 at 10:53
I believe this is commonly referred to as the "stable trunk" or "feature branch" model. –  sleske Dec 23 '11 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. –  AProgrammer Dec 23 '11 at 17:20
show 1 more comment

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

share|improve this answer
add comment

Your Answer


