A little over a year and a half ago some colleagues and I really started pushing for a more sane branching strategy. It was a bit of the wild west in terms of who could commit directly to master/develop and how things got merged in. Part of this was great in that it allowed us to iterate extremely quickly, but also caused some major problems when someone accidentally merged in some breaking code.

GitFlow is designed to work great for any sized team that is working in parallel on the same codebase. It has a process built in to handle branches for QA and branches that are production ready. On top of that it has good support for both hotfixes to branches live in production and bugfixes.

How It Works: The Basics

GitFlow was designed by Vincent Driessen back in 2010, but it really caught on back in late 2013/early 2014. The main design focuses around two main branches which never go away: master and develop. The head of master will always be a production ready and the head of develop will always be the stable branch for development.

From there it’s best to first check out the chart:

http://nvie.com/posts/a-successful-git-branching-model/

How It Works: Other Branches

Outside of the two main branches, original GitFlow has three more branch types: feature, release, and hotfixes. On top of that I personally endorse having a fourth branch type called: bugfix.

The feature and bugfix branch types always come off of develop. the feature branch is always written as feature/ticket-#-my-cool-feature. This is where all work for a new feature would be added. Once the feature has been reviewed and is ready it is merged directly into the develop branch. When a bug is found in the develop branch a new branch should be cut from develop and named bugfix/ticket-#-fix-for-bug. Once the bug has been fixed that gets merged directly into develop.

The other two branch types are more focused around deployment and releasing. release (release/ticket-#-ver-1_0_0) will be cut off of develop, similarly to feature and bugfix, but in this case it’s when we’re ready to release a new version of our software. Release versions are where we do our final set of tests and have product check to make sure that everything is working as expected. If any issues are found then we would cut a new bugfix branch and that would get merged into both develop and release. Once finalized the release branch will get merged into master and a new tag will be cut. Tags are the way in which the software is released to the customer. Everything customer facing should be discussed in terms of tags.

The final branch is the hotfix branch. Any bugs that are found on a tag need to be dealt with immediately since they are being seen by the customer. These fixes should always be done on a hotfix (hotfix/ticket-#-hotfix-issue) branch. Once fixed, these branches get merged into both develop and master.

Why it works

The beauty of GitFlow is that developers don’t get in each others way and that there is a process by which new things are created and how things get fixed. No one is confused as to where things stand and you can say with confidence that the master and develop branches will be stable for when you need to jump on something quickly.

Happy Ending

I can happily say that at this point we’ve switched over to running GitFlow on all of our repos and it’s made a world of difference to both current and new devs. If you have any questions about GitFlow or how I’ve helped implement it at places I’ve worked feel free to reach out.