Feature Branching
Feature branching isolates each change on its own branch until complete, giving teams parallel workspaces at the cost of long-lived divergence and harder merges.
Definition
Feature branching is a version control workflow where each feature or fix is developed on a dedicated branch created from the mainline and merged back only after the work is complete and reviewed.
Context and scope
Common in teams with release trains, infrequent integration, or work that must not reach the mainline until a coordinated launch.
Common misconceptions
- Feature branching is always safer because main stays untouched; long branches hide integration risk until merge
- A merged branch means the feature is ready to expose; deployment and release are separate
- Branching removes the need for continuous integration on the mainline
Anti-patterns
- Letting a feature branch live for months and merging it as one giant change
- Cutting release branches that immediately diverge and never receive fixes
- Running CI only on the branch and not on the merged result
Related concepts
Authoritative source
How it works
An engineer creates a branch from the mainline, commits the feature over days or weeks, and opens a pull request when it is complete. CI runs on the branch, reviewers inspect the diff, and the branch merges back through a merge commit or squash. Release branches may be cut from the mainline for stabilization.
When to use it
Feature branching suits coordinated launches, teams with infrequent integration, and work that must not reach the mainline before a date. It gives each change an isolated workspace and a natural review boundary. Compared with trunk-based development, it favors isolation over integration frequency, which helps when changes are large or risky but hurts when branches live for weeks.
Trade-offs
Long-lived branches drift from the mainline, so merges grow large and conflicts become semantic, not textual. Reviewers face huge diffs, and integration bugs appear only at merge time. Frequent rebasing and short branch lifetimes reduce the pain; feature flags can decouple merge from launch.
Example
A team builds a new billing screen on feature/billing-v2 for three weeks while other engineers change the shared pricing module. At merge, the branch has sixty conflicts and a broken assumption about tax calculation, delaying release by two days.
Misconceptions
Feature branching is not inherently bad; the risk is branch lifetime, not branches themselves. A merged branch does not mean the feature is safe to expose, because deployment and release are separate decisions. Nor does branching remove the need for continuous integration on the mainline.
Related concepts
Trunk-based development integrates daily and avoids long divergence; code review is the merge gate for any branching model; progressive delivery exposes the merged feature gradually.