#16: The Ultimate Branching Strategy
From Junior to CTO Weekly Thoughts
There are many strategies for managing branches in your software development process. In The Ultimate Contribution post, I mentioned branches and merge requests, which explain a single contribution but not a collaboration between many developers. Collaboration can be organized with different branching strategies. The best one for you depends on certain aspects of your context. In this issue, we will discuss when to apply which one.
As before, my experience is mainly related to Git, so you can try to map some ideas to another VCS, but I didn’t have the intention to make it compatible.
Overview
There are no best or worst options, but there are more appropriate ones for your case.
First of all, let’s name what options are widely used:
Git Flow
Trunk-based Flow + Feature Flags
GitHub Flow
Gitlab Flow
One Flow
You might find other strategies, but I want to show you a framework for choosing the best from the available options.
We will compare and find the right place for these strategies, but first, let’s formulate properties for atoms of these approaches: Commit, Branch, Tag.
Atoms
Commit
An immutable state of the repository. The key properties of any commit:
uniquely identifies a change and state of the repository since the change is applied
immutable state
Branch
Dynamic pointer to a commit that isolates and tracks a set of changes. The key properties of any branch:
dynamically identifies a set of changes
simplifies work with an isolated set of changes
Tag
Static pointer to a commit that simplifies the detection of a particular state. The key properties of any tag:
names a state
manage static identification. For example, 1.0.0 statically identifies sources for a particular version of the component.
Before diving deep into strategies, let’s understand what properties will impact choosing the most appropriate one.
Properties that impact strategy choice
The branching strategy is a living organism that should adapt to your current context.
Team size
Adaptation means starting from the simplest option for a single developer (if that is your case) and, evolutionary, coming to the best option for a team.
Team skills
Your team's skill level impacts the choice because some strategies protect you more from beginner’s mistakes than others.
Code organization strategy
The more projects are stored inside the same repository, the more people collaborate and resolve conflicts - the more important it is to consider options that minimize conflict rate and improve continuous integration. At the same time, if you can avoid complexity because there is no collaboration, why not?
Desired frequency of delivery
Do you want to deliver every single feature available immediately and turn them on/off via feature flags, or you do mostly not care about granular feature tuning? This matters.
Strategies
Common practice is that a feature branch is short-living, so since the feature is merged, you should remove a feature branch, but at the same time, if release branches exist, they should be removed only if your context allows that.
Git Flow
There is a chance that the quantity of articles about Git Flow is more than the quantity of atoms in the Universe. The strategy is pretty mature, but the disadvantages of it are well-discovered as well.
This approach is generally good, but there is a place for some redundancy and potential inconsistency.
Every next merge will require a run of the CI Pipeline, which means that if you checked something manually, it is not guaranteed to have the same on production because, after your check, the artifact will be rebuilt again (on release → main merge) so something might go wrong.
You have two long-living branches main & develop. That potentially might introduce inconsistency, for example, because you might forget to merge back your fixes from the release branch
Team size: works for any team size, but it is overkill for a team of one
Team skills: if you have fewer QA resources than needed, a low level of QA automation, and some developers have junior-level
Code Organization Strategy: a single main branch might sound uncomfortable for mono repositories with many teams
Desired frequency of delivery: at max once a few weeks
Trunk-based Flow + Feature Flags
The trunk is your main branch (whatever you name it), a place of Continuous Integration. Developers commit their changes as early as possible and create not feature branches but branches by abstractions, using feature flags to manage what is enabled in production. Merges should happen every day to guarantee a high level of continuous integration. Watch the video of the week at the end of the issue to get more details.
The approach is super simple but requires more effort and cost to implement. Feature flags require extra infrastructure, feature flags need to be maintained, feature flag cleanup process should be in place. At the same time, you get an opportunity to perform A/B testing for free.
Team size: works for any team size (the simplest option for one developer)
Team skills: a highly skilled team and a high level of QA automation. Developers have a strong understanding of how to manage abstractions with feature flags
Code Organization Strategy: You get the most profits from mono repositories because all the code is integrated as quickly as possible. But in general both ways are fine.
Desired frequency of delivery: as soon as abstraction is available in the main branch, it should be delivered. This is the fastest strategy of delivery.
GitHub Flow
This flow looks pretty similar to trunk-based approach. But the difference is that it doesn’t require daily merges.
Team size: works for any team size (the simplest option for one developer)
Team skills: mixed team with different levels, QA resources are enough to guarantee feature quality
Code Organization Strategy: you get the most profits from mono repositories because all the code is integrated as quickly as possible.
Desired frequency of delivery: as soon as a feature is available in the main branch, it is deployable.
GitLab Flow
GitLab transforms the idea of branches into subsequent pipelines of changes. You merge feature branches to the main branch (for GitLab Flow it is the main long-living development branch), but you can also introduce any other branches you need, like “production”, “pre-production”, etc. The problem of inconsistency here is presented as well but in another form because you have long living branches for main and production.
Team size: works for any team size (but overkill for a team of one)
Team skills: mixed team with different levels, QA resources are enough to guarantee feature quality
Code Organization Strategy: does not work if many projects stored in the same repository
Desired frequency of delivery: at max once a few weeks, not more often
One Flow
This approach has some variations, and I really recommend you spend some time on the original article. The main idea is that you still have only one long-living branch and use another one only if you want to simplify navigation for bug fixes. The approach is pretty flexible and can be constructed according to your requirements
Team size: works for any team size (moderate complexity for one developer)
Team skills: mixed team with different levels, QA resources are enough to guarantee feature quality
Code Organization Strategy: appropriate for both mono/micro repositories
Desired frequency of delivery: release complexity is not high, but I’d say that it is designed for at max once a few weeks
Conclusion
Let’s review a few cases:
The best for one developer and moderate QA automation: GitHub Flow
The best for skilled teams and high QA automation: Trunk-based Flow
The best for moderately skilled teams, low QA automation, and complex release acceptance process: GitLab Flow
The best for moderately skilled teams, low QA automation, and simple release acceptance process: One Flow
There is no “the best strategy” because the most appropriate depends on your case. GitFlow is generally outdated because there are other simpler options to achieve the same results. Since you have this knowledge, you can choose or even design the most appropriate one. In the next issue, we will talk about The Ultimate Repository Configuration and get a better understanding of how to manage all these guides.
The Video Of The Week
Resources
Trunk-based development
https://trunkbaseddevelopment.com/
GitHub Flow
https://githubflow.github.io/
GitLab Flow
https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/
One Flow
https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow