What is a feature branch?
When several developers are working on the same code base then it would be difficult for them to work on the same code base without their work overlapping or overriding each other’s changes.
The simple solution for them is to make a copy of the codebase so that each developer can work on their own features. Imagine it like a tree where the master branch may be referred to as the trunk (also referred to as main or mainline) and each copy of the codebase is referred to as a branch. Then, when the team deems the feature ready, they would merge this feature back into the trunk.
The process of incorporating any changes made into the master trunk is known as merging. Feature branch development and merging is handled in version control software such as Github, GitLab or Bitbucket.
The upside of feature branching
In simple terms, whenever a developer wants to work on a feature, they would open up a branch where they will do all the work on the feature in this branch and then once that is complete, they would integrate these changes with the rest of the team by performing mainline integration once the feature is complete.
Collaboration
A feature branch, in that sense, allows developers to collaborate in an efficient way around a central codebase by keeping any changes to a feature in a specific branch so changes will not affect other developers.
A feature branch also allows agile teams to detect bugs as each bug lives within its own branch, which enables them to see which issues are in progress and which are ready for release. This is done through pull requests where any changes can be discussed before merging it to the master by giving developers the opportunity to review these changes before they are finally merged into the mainline.
To sum up, the basic principle underlying this concept in the words of Martin Fowler:
Put all work for a feature on its own branch, integrate into mainline when the feature is complete.
The downside of feature branching
Merge conflicts
On the one hand, feature-driven development helps to manage large-scale projects by allocating resources depending on the needs of each feature.
On the other hand, it may, at some point, become difficult to manage thousands of branches so for example, if a feature branch remains in development for too long then it might conflict with other branches when merging. It could be that a branch works perfectly fine on its own but once merged it no longer works due to the changes that took place in the mainline in the meantime.
This results in delayed deployment as often many pull requests would need to be analyzed to resolve any merge conflicts. Also, it should be noted that the rest of the team will not be able to see any changes until the branch is merged so there is no quick feedback leading to serious delays.
As an example, let us envision a situation where one developer’s feature cannot be released independently until the other developer’s feature is complete. This means that multiple independent streams of work become so entangled that one cannot be released without the other, meaning that these features cannot be released independently. The solution seems pretty straightforward, that is through the use of feature branching. But now the problem of painful merges arises especially when developers are working separately on different branches within different timelines without any integration and thus not pushing code continuously to a shared branch.
To sum up, there is a risk of major merge conflicts when parallel feature branches contain significant changes. This gives rise to what is referred to as ‘merge hell’. This comes as a result of merging several long-lived branches, which may be avoided if you merge into the trunk several times a day. This alternative method is known as trunk-based development.
Feature branching using feature flagging
The best solution is to use feature flags and practice continuous integration. Feature branches are often coupled with feature flags to enable the activation and deactivation of a feature and allow it to be shown to a select subset of users. In feature branching, feature release management is tied to code deployments.
This is where feature flags come in. Using flags allows in-progress changes to be pushed into a shared branch without blocking the release from that branch so developers can release the completed feature while keeping incomplete features flipped off. Therefore, developers are in full control of feature lifecycles without relying on code deployments.
So we can conclude that feature branching is a useful technique to allow all work done to be kept away from the shared codebase until it reaches completion. To be able to achieve optimal results with feature branching, it is often necessary to complete features within a day or two at the most as teams that take weeks or months to complete a feature will run into difficulties.
In other situations where teams are looking for an efficient product release through quick feedback, they turn to continuous integration, which helps lessen merge conflicts by continuously merging all changes into the mainline. Developers under this method, referred to as trunk-based development, push code directly into trunk as soon as possible, usually in less than a day so when developers create a branch, it is usually short-lived.
