Jon Purdy has the right idea.
git flow makes the actual management of these branches easy, as well, and branch management is an argument for moving to
Let's start with a basic rundown of
git, since you're coming from the
git perspective. Consider in
git the following:
\ / / /
Above, you branch
develop (denoted by the
\), and branch
develop to a
feature branch. We merge those branches back up (denoted by
/), with commits (
-) along a branch. (If there's no commit but the merge is way to the right, there are
. indicators to show that the next
- is the next commit).
Easy enough. What if we have a hotfix in our main release?
\ / / / \ /| /
\ / / / -hotfix-- V /
\ / \ V /
develop branched from
master. The bug discovered in
master was fixed by branching from
master, fixing it, and merging back into
master. We then merged
develop, and then
feature2, which rolled the new code from
hotfix into these branches.
When you merge
feature2 back to
develop, its history includes
develop with the
develop is merged into
feature2 with the new code from
master, so merging
develop back to
master will happen without a hitch, as it's based on that commit in
master at that time—as if you had branched from
master at that point.
So here's another way to do that.
\ /\ /
Your 1.0 releases get tagged—
1.0.3, and so forth.
Now here's a trick: you found a bug in 1.0 and it affects 1.1, 1.2, and 1.3. What do you do?
You branch off your latest or earliest maintained release and fix it. Then you merge your new
hotfix branch into
1.0. Don't branch from each of the maintenance version branches; don't merge
master or merge
master back into
1.0. Take the one
hotfix branch and merge it into all your version branches. If there are conflicts, it will tell you; review your code to ensure the changes are correct (
git diff is your friend).
Now that specific change is applied everywhere. The lineage is branched, but it's okay. It's not haphazard. Tag the
1.3 head as 1.3.17, merge it into every feature-in-progress branched from
1.3, and move on.
git flow extension helps manage these maintenance, feature, and hotfix branches for you. Once you get the workflow down, this is trivial and takes a huge amount of trouble out of source code management.
I've seen this done on programming teams, but I've not worked that deeply as a programmer myself, so I'm still getting my head around the day-to-day workflow myself.
gittag after each successful build? This would have the added advantage that it makes it really clear which
gitcommits have build issues or test failures, since they would remain un-tagged.