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:
develop are the main branches 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
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-branches and a designated
develop-branch are the two biggest differences from how we did it at Opbeat:
feature-branches derived from
master, and the release came directly from the
feature-branch as well. No
feature-branches and the occasional
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
master, thus making the
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.