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