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 '11 at 9:51
  • So what usually goes into the master branch? (up until now I always do everything there) – laurent 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

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 '11 at 10:28
  • +1 Pretty much what we use at work, and it really does work. – Ed James Dec 23 '11 at 10:53
  • 1
    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
  • 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 '11 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? – Michael Durrant Apr 14 '15 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. – AProgrammer Apr 14 '15 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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