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