Once work on a feature branch is completed, a merge of the feature branch back into the main codebase (or “trunk”) is attempted. The longer a feature branch is open, the more likely that the merge process will prove difficult.

Isolation, For Better or Worse

Feature branching became especially popular with the rise of open-source projects. The isolation it provided allowed independent developers to work on feature contributions at their own pace, leaving the main branch untouched until after a code review and merge. The isolation provided greater stability and a clearly defined quality gate.

In commercial settings, where multiple developers are working full time and the cost in time and lost momentum due to merge conflicts is higher, the isolation created by a feature branching approach can be a significant liability. Worse still, the relationship between the length of feature branches and the complexity of merge conflicts can lead to a perverse incentive where the team avoids merging even longer. This, in turn, increases the chance of a catastrophic “merge hell” situation that can derail a project and/or lead to developer burnout.

Short-lived Feature Branches, Trunk-Based Development, and Continuous Integration

Teams that use feature branches and want to limit the overhead of complex merge conflicts have shifted to the use of “short-lived” feature branches, where changes are scoped down into smaller chunks that can be completed and merged back into the main branch within hours or at most a few days.

As feature branches become shorter they become nearly indistinguishable from trunk-based development and continuous integration. The goal with these practices is to constantly be merging back to the trunk in order to detect merge conflicts as quickly as possible.

When a developer commits an hour of work and is notified of a conflict in less than five minutes, it’s much easier to triage and resolve the conflict than if they have to sift through days or weeks of changes by multiple developers. The key benefit is forward momentum and freedom from the fear of multi-hour or multi-day merge conflicts.

Short-Lived Feature Branches and Feature Flags

A large feature may take days or weeks to complete. Decomposing it into smaller chunks that can be incrementally built, tested and committed in less than a day isn’t always practical. Even if that chunking is possible, it might result in various smaller components of the feature being live in the code before the feature is complete and ready for users.

Feature flags provide a consistent and safe way to control access to these partially completed features, allowing developers, testers and internal stakeholders the ability to execute the code in any environment, including production, without exposing the partially completed work to users. As a result, feature flagging has become a common practice adopted by teams moving to short-lived feature branches, and a must-have for teams that practice trunk-based development and continuous integration.

Short-Lived Feature Branches and Refactoring

Refactoring is the practice of improving the quality and supportability of software by revisiting existing code and making changes. Refactoring fights the natural tendency for entropy and “code smell” to increase over time. It’s most effective when it’s done frequently and when it causes the least interruption or distraction to the team. Since it’s common to run into merge conflicts when refactoring is performed, refactoring is far easier to accomplish in a short-lived feature branch or full-on continuous integration practice. Conversely, teams that use long-running feature-branches have a strong disincentive to even attempt refactoring, let alone make it a regular and consistent practice.

Short-Lived Feature Branches: The Best of Both Worlds

Feature branches, when kept short, provide the benefit of a well-defined process for review and acceptance of changes that made them popular in the open-source movement and the benefit of continuous integration’s reduction of complex merge conflicts.

To go deeper on this topic and the relationship between short-lived feature branches, feature flags and trunk-based development, have a look at the blog post, Feature Flags vs. Feature Branches.