Feature Branching vs. Trunk-Based

---

Origins

Feature branching as a defined pattern was articulated by Vincent Driessen in 2010 as GitFlow¹. GitFlow specified a structured branch model with main, develop, feature, release, and hotfix branches, each with defined merge paths. The article became one of the most-shared software engineering posts of the early 2010s and shaped how a generation of teams adopted Git.

Trunk-Based Development is the alternative pattern, with one mainline and very short-lived branches. The two approaches make opposite bets about where the risk lives in software delivery: feature branching isolates work to protect it; trunk-based integrates work to surface conflicts early.

The Two Models

Feature Branching (GitFlow and Variants)

Each feature lives on its own branch. The branch starts from a development or main branch, accumulates commits as the feature is built, gets merged via pull request after review. Branches may live days, weeks, or longer.

Typical structure (GitFlow):

• main — production-ready code.
• develop — integration branch for features in progress.
• feature/* — individual feature branches off develop.
• release/* — release preparation branches.
• hotfix/* — emergency production fix branches.

Trunk-Based Development

One mainline branch. Developers commit directly to it, or use very short-lived branches that merge within hours. Incomplete work is hidden behind feature toggles.

What Each Model Optimizes For

Feature branching optimizes for isolation

Work-in-progress doesn't affect other developers' work. Code can be reviewed thoroughly before merging. Branches feel safe — if something is wrong, only the branch is wrong, not the trunk.

Trunk-based optimizes for integration

Conflicts surface immediately when they happen, while they're small and easy to resolve. The whole team sees the same code state. Continuous integration tests run against actual integrated code, not isolated branches.

The Trade-offs

Conflict cost

Feature branching defers conflicts until merge. Trunk-based encounters conflicts continuously but each is small. The cumulative conflict cost is usually lower with trunk-based because diverging changes haven't had time to spread.

Code review

Feature branches accumulate enough code to make review meaningful as a batched activity. Trunk-based requires fast, often smaller reviews — either continuous via pairing, or async via small PRs reviewed in hours.

CI signal quality

Branch-level CI tells you the branch passes tests. Trunk-based CI tells you the integrated code passes tests. The former can be green while the integrated reality is broken; the latter cannot.

Release coordination

Feature branching makes release-based versioning natural — the release branch is the artifact. Trunk-based makes continuous deployment natural — every commit is potentially shippable.

Team coordination overhead

Feature branching lets developers work without much awareness of others. Trunk-based requires team-level awareness — refactoring while someone else is in the same code becomes a coordination concern.

What the Evidence Says

The DORA research² consistently identifies trunk-based development as one of the strongest predictors of elite delivery performance. Teams with short-lived branches and frequent integration outperform teams with long-lived branches on deployment frequency, lead time, change failure rate, and recovery time — all four DORA metrics.

The result is robust across team sizes, codebase ages, and industries. It doesn't mean trunk-based is always right; it means the cost of long branches is usually larger than the perceived benefit of isolation, even when teams feel the opposite.

When Feature Branching Fits

• Open-source contributions: external contributors can't be expected to merge to your trunk multiple times daily.
• Regulated environments: where every change requires sign-off and audit, the gate cycle time forces longer branches.
• Multi-version maintenance: teams maintaining several released versions in parallel need branches per supported version.
• Slow CI: teams whose CI pipeline takes an hour can't realistically commit to trunk multiple times daily. (Fix the pipeline before deciding the model.)

When Trunk-Based Fits

• Single mainline product: most modern SaaS and web products fit naturally.
• Continuous deployment goals: trunk-based is the only branching model that supports it.
• Strong test coverage: the safety to merge to trunk continuously comes from automated test confidence.
• Toggle infrastructure available: incomplete work needs to hide behind toggles to merge safely.
• Fast CI pipeline: under 10 minutes for the fast loop.

The Hybrid Middle

Most teams don't actually run either model purely. The pragmatic middle:

• One mainline branch.
• Very short-lived feature branches (target one day or less).
• Pull-request review before merge, with target turnaround of hours.
• Feature toggles for incomplete work.
• Direct trunk commits for low-risk changes (typos, docs, small refactors).

This hybrid captures most of the trunk-based benefits while preserving lightweight review checkpoints. The discipline that matters is branch duration, not whether branches exist at all.

Common Pitfalls

• GitFlow for a SaaS team: applying release-branch-based workflows to a continuously-deployed product produces unnecessary complexity.
• "Trunk-based" with two-week branches: naming the practice without honoring the duration. The branch length is what matters.
• Branches as work-in-progress storage: developers using long branches to hide incomplete work rather than building toggle infrastructure.
• Tool change without practice change: switching git workflow without changing CI investment, review cadence, or toggle adoption.
• Religious adoption: insisting on pure trunk-based when the team's context (open source, regulated, multi-version) genuinely doesn't fit. Pragmatic adaptation is better than dogma.

Coaching Tips

Measure Branch Age

The metric makes the choice visible. Teams averaging week-long branches are not trunk-based even if they think they are.

Match the Model to Context

An open-source project genuinely needs feature branches. A SaaS team usually doesn't. Recommend pragmatically, not dogmatically.

Fix CI Before Migrating

A team with a 60-minute pipeline can't realistically merge to trunk multiple times daily. Fix the pipeline first; then the model becomes possible.

Build Toggle Infrastructure First

Without feature toggles, trunk-based forces a choice between long branches and broken trunk. Build the toggle layer before pushing the branch change.

Reduce Review Cycle Time

Long PR review times produce long branches by default. Coach faster review before recommending shorter branches.

Stage the Transition

Teams don't go from week-long branches to direct trunk commits in a week. Stage by halving target branch lifetime each month.

Summary

The branching model debate is sometimes presented as a religious choice. The evidence is more practical: trunk-based outperforms feature branching on the metrics most teams care about, in most situations most teams encounter. The teams that genuinely need feature branching usually know why — multi-version maintenance, open-source contribution flow, regulatory gating — and apply it deliberately.

For most teams, the right move is to shorten branch lives aggressively, invest in the supporting infrastructure (CI, toggles, fast review), and accept that the resulting practice looks more like trunk-based than like GitFlow. The migration is harder than it sounds; the payoff over months is significant.

Back to Technical Practices