Git Flow for shipping companies

At my place of work, we're working out about changes to our daily workflow in the development teams. One of these changes concerns the branching strategy for our git repos, and because I very much liked how we did it at Opbeat, I'm writing it up briefly here for posterity and easy sharing:

Git Flow is a popular branching strategy for development teams, and I'm sure it works well for people who have a relatively strict release scheme. At Opbeat, we said "fuck it, ship it", so the bastardised version of the git flow strategy suited our workflow really well.

It Git Flow, you essentially work with five different kinds of branches:

  • master
  • develop
  • feature-branches
  • release-branches
  • hotfix-branches

master and develop are the main branches and feature, release and hotfix-branches are supporting branches. There's nothing technically special about them, but the use is particular.

As I understand Git Flow, you merge your finished work from your feature-branch to develop, and once you have a collection of commits you want to release, you merge those to a release-branch which you then give a specific tag. Shipping the release then also means merging code from release to master.

Having release-branches and a designated develop-branch are the two biggest differences from how we did it at Opbeat:

Opbeat Git Flow Strategy

All new feature-branches derived from master, and the release came directly from the feature-branch as well. No release-branch, no develop-branch, just feature-branches and the occasional issue or hotfix-branch.

The reason for deploying feature-branches is that master is always the latest state in which you were certain everything worked as intended. That means rolling back to a working state is a matter of deploying master again, removing the commits deployed with your feature-branch from production.

Once you've made sure your code works as expected, you merge the feature into master, thus making the HEAD of master and feature identical.

This way of working demands frequent pulling and merging from master into your ongoing feature-branches (to avoid having too many merge conflicts, which in any way can't be avoided completely), and it strongly encourages getting code out from your local machine to production when it's ready. Stale code breeds merge conflicts and we any way wanted to keep the shipping pace up, so it fit our mode of working really well.

To keep our developers from shipping at the same time, thus creating a conflicting state on the servers, we used a small Slack-bot that would enable you to "claim" the server. That way it was apparent for everyone in the team who owned the server at any point, and that you should keep your hands off of it.

One last, but very important part of this workflow was code review and tests. Every working bit of code should have a test, and our coverage was (as I've later found out) exceptionally high. That helps you feeling more secure before shipping your code, and combined with ongoing code reviews after opening a pull request strengthens that feeling even more.

I'm not claiming this way of working is ideal, or even better, than using Git Flow or whatever strategy your team of developers use. It worked really well for us, because it fit the mindset of the team, and it was clear for everyone how we did it. Getting everybody on board with a specific modus operandi is always better than doing it in a "right" way that doesn't fit the way your team actually do their best work.