As a software engineer, one has to constantly stay on top of the latest trends, strategies and technologies in order to stay competitive in a very cutthroat industry. One of the things we have to keep on top of is version control systems(VCS).
Brief history of Version Control Systems
I won’t rewrite what’s already been written in this online course. What one needs to keep in mind is that there are 2 types of version control: centralised and distributed. If you’ve ever used CVS or Subversion then you’d be familiar with centralised version control. On the other hand if you’ve used GIT or Mercurial, then you are using distributed version control. Most companies has migrated from centralised to distributed version control due to the advent of remote working and the mass adoption of the internet.
This article will focus on GIT, but there’s no reason why this branching strategy can’t be used in Mercurial too.
Existing branching strategies
Most developers would be familiar with either the Gitflow or the Hubflow (aka GitHubflow) branching strategies. But what are they? Let’s have a quick look at both strategies. Gitflowwas introduced by Vincent Driessen in 2010 and has been a favourite of developers worldwide. The other, is mostly just an extension from the Gitflow branching strategy, however, the master branch should stay deployable to production and some companies uses the master branch to deploy to production instead of creating a release branch. Unfortunately, with the use of distributed VCS, this can end up in bugs being deployed to production and due to the merging of code from different teams, one could run into issues when trying to determine what’s in production and deploying hotfixes.
Side note on proper deployment of features
I would highly recommend making features available to production through the use of feature toggles. There are quite a few strategies how to do this, however, I find the way Spotify manages features are quite useful. There are many good article out there, however, I found this article useful.
The proposal of a new branching strategy
Unfortunately, I’ve seen first hand how these branching strategies can either overcomplicate development or make a simple 1 minute hotfix for production run into hours or merging hell. So with this in mind, I thought on how can we a) make development simpler and b) make hotfixes easier to implement and merge.
So let me explain how this branching strategy works. The master branch is always the source of truth. In an Agile environment, the release version number is usually already decided before the sprint starts. So we’ll create a branch, v0.0.1-dev which contains the planned release number appended by “-dev” to denote that the branch is a development branch. This branch will be used for all feature and bug fixes. This branch will also be used to deploy to a development or UAT environment.
Once we are happy with the features or the sprint has finished, we merge the branch, v0.0.1-dev into master. Now we create a release branch called, wait for it, v0.0.1 and we deploy that to production. One can easily see what’s in production when using this branching strategy.
But what happens when we find a bug in production? Well, we create a hotfix branch on the released branch, and because we know which branch is in production, there can be no ambiguity about which branch the hotfix should be created on. We deploy this hotfix branch to UAT for testing and once it’s cleared, we merge it back into the release branch. We tag the release branch with a patch number v0.0.1.1. We then merge the release brach back into the master branch.
If a feature branch has been created since the release of the v0.0.1 branch, we will merge in the changes from the release branch into the feature branch. The release branch will not be closed until the next end of the sprint when the next release will go into production. In which case a new branch will be created called v0.0.2.
I call this branching strategy the devi8flow branching strategy after the company that uses this branching strategy, devi8 consulting. If you have some questions, please comment on this article and I’ll do my best to answer any questions you may have.
