Replacing our Git branching strategy

The branching strategy we use at work is one that has evolved from us tentatively learning how Git works, reacting to our mistakes and avoiding the problems that have arisen. I have, on more than one occasion, had to rebuilt the history due to errant merges going into master. Mistakes can also happen resulting in contamination of release branches, or failure to update all required branches, including master. While it works for us, the fact that it can occasionally bite us on the bum, and the fact that I’m having difficulty documenting why we do what we do both point to the conclusion that the strategy is flawed. So I’m binning it, although not until I have a working alternative that we’re happy with.

Key to this new strategy will be how changes are reapplied back to the main and release branches. Rather than simply taking peoples word for why you should or shouldn’t be doing merges or rebases in Git I’ve gone right back to basics and made sure I fully understand what is going on when you merge or rebase and what the implications are – to the point of setting up parallel git repositories and testing the same operations with different strategies on each.

Secondly I need to look at putting branches back on origin. Being distributed can make git a pain in the backside for some things and sometimes you really do just need one place to go look for data. A prime example is Fisheye/Crucible which we use for viewing our git repositories and performing code reviews. Since our JIRA workflow looks to Fisheye/Crucible for information about code changes and code reviews we push all branches to origin. Would a move to Stash remove this need?

Thirdly is our habit of keeping all branches. This leads to a lot of clutter and may or may not be related to the first two points; I’ll need to do more investigation on that front, however, I suspect I’ll be able to greatly reduce the number of branches we have.

What I suspect we’ll end up with is a strategy where most branches are taken from master, with master being rebased back into the branch before the branch is merged into master and then deleted. Release branches will also be taken from master as needed. Fixes to release branches will be branched from the release branch, the release branch rebased back in when work is done, and then the fix merged into the release branch. The release branch will then be merged back into master. At some point the release will be tagged and deleted. Pull requests using Stash will hopefully obviate the need to push feature branches to origin. How well that plan survives contact with reality I don’t know.