Gitflow Workflow

20 February 2018

Photo: Unsplash

When starting any coding project you should use Version Control software. Used to track changes to your code this software also allows for many people to work on the code at once. It may seem overkill but these systems provide a safety net for even the smallest shell script.

While there are many options out there, the most popular option is Git. Originally developed by Linus Torvalds the software quickly gained fans in the Linux Kernel community. Open sourced and released under a GNU licence, a community of developers and tools grew around the software. Github, a service designed to simplify the process of working with Git has also helped its growth.

There are many good tutorials for learning how to use Git such as:

• Git - The simple guide
• Git Immersion
• Git Guru

So I will not cover the basic’s here.

The issue I want to address is when you start a project that has the potential to grow fluently. It is easy to work with Git by branching off of master and doing some work and then merging it back in. In fact, there are a lot of very large companies that do just that. But, if you’re a small company with limited resources it is hard to track release and development branches. If you use a centralised service such as Github or Bitbucket they offer integrations. For example, these integrations will allow you to automate your deployments via Git. They may also hook into your work management software such as Jira. Given that complexity grows in line with the number of branches, what you need is a workflow that brings some order.

Enter Gitflow.

Gitflow is not new. In fact, the article referenced above dates back to 2010. Gitflow specifies a way of setting up your Git repo and working with the branches. Its aim is to segment working code from development code. It allows developers to isolate features in development away from testing. Once tested the code can then be pushed to Production.

Within the workflow there are 4 main branches:

• Master - This is your production code. The code on this branch should always be working, tested and deployable. No development changes should never be merged here directly.
• Develop - This is your developers currently building code. Think of it as the master branch for development. Feature branches are pulled and merged to develop.
• Release - The release branches are pulled from your develop branch and merged into the master and develop branches. The branches live for as long as you need to test the code/features within them.
• Hotfix - These branches are pulled and merged from the master branch and are used for performing small bug fixes in your production code.

This set up gives you a lot of flexibility. You can have a team of developers working through your features for a sprint at the end of which you create a release branch. That branch is released to your staging site. While being tested your developers move on to their next work. Oh, wait, someone found a bug in the release branch and one of your developers fixed it. That fix lives in the release branch until the testing is complete. A couple of days later the testing is completed and the release branch is merged back to the develop branch. This means that the fix that was made is retained. The release branch is also merged to master and pushed to your production site. All the while this was happening multiple feature branches have been created, reviewed and merged by the developers. But, it is easy to track what is going on, which is the power of the workflow.

Gitflow is adaptable to your DevOps workflow as well. For example, at Open Energy Market we have Azure hooked up to our master branch. We have a Staging branch set up which our Azure Staging environment connects to. When commits are pushed to either branch it triggers an automatic build and deployment. Due to some of the bigger features, we have been working on of late, we have been able to manage many release branches with ease.

Gitflow’s popularity has lead to its adoption in many tools such as the Source Tree and Git Kraken GUI’s. There are also many console-based implementations, the best of which is nvie/gitflow.

There are other workflows available for Git. From my experience, Gitflow is ideally suited to small teams with limited resources. Once you have your development process then Gitflow is a great supporting process.

Have you used Gitflow for a major project? Are there better workflows for your usage? Message me via twitter or email.