Tag Archives: git

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.

Revisiting Git

I first discovered Vincent Driessen’s branching model¬†when I was investigating Git a couple of years ago. At the time I was desperate to get away from the merge issues that we were having with Subversion and was looking into both Git, and different branching models using it. Given the steep learning curve with Git we decided not to complicate things further and to stick with our old branching model; albeit with a slight change in naming convention borrowed from Vincent.

Now I’m a little more comfortable with Git it’s time to revisit our branching strategy, and use of Git overall. I’ve looked at Vincent’s branching model again, and looked at git-flow in great depth and have concluded it’s still not for us, however, the idea of codifying the workflow, and providing git extensions to aid using the workflow appealed to me immensely.

Currently we’re doing little more than branching off master for issues, with each issue (be it a new feature, or bug fix) living in its own branch. Issues are rebased into master when they’re done. Releases are also cut from master and any patches (either to the release version in QA, or to the release version in live) are cut from the release branch, rebased into that and then rebased into master.

In order to simplify our JIRA and Fisheye/Crucible setup we also push issue branches to origin making them visible from a central point, as well as providing a backup. These branches are considered private and not used by others.

Since we have tight control over all the branches a rebase only strategy works fine for our team, although we have had some problems caused by accidental merges. The next step is to improve the workflow and the merge/rebase strategies to survive all situations, codify these steps and then script them – something I’ve already started doing.

I’m also looking at this as a potential opportunity to possibly move away from Fisheye and Crucible to Stash, potentially saving some money whilst keeping the tight JIRA integration.