So recently having to really look at the branching strategy we employ at my work for some of our products. We followed something similar to Git flow strategy popularised by Vincent Driessen but didn’t have the full model as he discusses in his post.
We essentially had master and develop branches in which master was production-ready and hotfix branch whereas develop was the constant integration branch. It worked fine until the team started to grow. The challenges were that even though developers were mainly using develop branch, there was no clear way for them to understand at which point the the branch diverged for the next release or a hotfix. They were heavily reliant on the scrum master instead of a process.
Yes, I know, milestones and labels can be used to act as flags while develop branch is constantly changing none of them act as a gate or a check point for people to stop merging to develop branch. We had to add another layer that could separate work on current release, any hotfix or work on future releases without creating a blocker for any of the developers, testers and operational personnel.
We decided to follow the fill git workflow model. Once the code freeze happened, a temporary release branch was created off develop branch, which had clear benefits for the team:
1) It allows for developers (especially true in a large or growing team) to carry on working on feature branches and merging into develop branch without effecting the current release cycle and testing frameworks in place.
2) The release branch also provides accountability for a team in a product strand to see and schedule their features according to the roadmap.
3) It is a massive help when it comes to streamlining and scheduling a release process especially from an automation point of view. You clearly know when the code freeze happened but you also know exactly when the branch diverged and you know exactly what / when is going to be a bug fix within the release branch.
4) Testers life becomes easier, they know exactly what is included in the release branch and if you couple that with provisioning of release environments (which I will talk about in another post), the benefits outweigh the costs.
5) Everyone knows exactly how the release looks like and when this (or parts of this) process gets automated, it works even better.
Finally I would say that we can already see the clarity in this workflow clearly a homage to Vincet’s idea which even though is almost a decade old but still holds true.
Recommended Reading:
http://nvie.com/posts/a-successful-git-branching-model/
