Trunk-Based Development

---

Origins

Trunk-Based Development is older than the Agile movement. Large engineering organizations — Google, Facebook, Amazon — have run trunk-based for as long as they've run continuous integration. Paul Hammant has done the most to articulate the practice for the broader industry through trunkbaseddevelopment.com¹, and the DORA research² consistently identifies trunk-based development as one of the strongest predictors of delivery performance.

The model became less common during the GitHub-and-pull-request era, which made long-lived feature branches culturally normal. The pendulum has swung back as the costs of long branches — merge conflicts, integration debt, "merge hell" — became visible at scale.

The Core Model

Trunk-Based Development has two defining properties:

• One trunk: a single shared mainline branch (typically main) is the integration point for all development.
• Short-lived branches: developers may create branches for individual changes, but those branches live hours or at most a day or two. Every developer merges to trunk multiple times daily.

Some teams skip branches entirely and commit directly to trunk; some use very short feature branches with fast pull-request review. The defining property is duration: long branches violate the model.

What Makes It Work

Trunk-based development depends on several supporting practices. Without them, it collapses.

Continuous Integration

Every merge to trunk triggers automated build and test. The trunk must stay green; a broken trunk blocks everyone. See DevOps Integration (CI/CD).

Feature Toggles

Incomplete features merge to trunk hidden behind runtime switches. The code is integrated continuously; the user-visible behavior is controlled separately. See Feature Toggles.

Strong Test Coverage

The trust that lets developers merge to trunk multiple times daily comes from test coverage. Without it, merging feels too dangerous and branches grow.

Code Review Discipline

Pull requests, if used, must be reviewed and merged quickly — usually within hours. Multi-day review cycles produce long-lived branches by default.

Why Long Branches Hurt

• Merge conflicts compound: a branch that diverges from trunk for a week has many conflicts with the work everyone else has been doing. The conflicts are harder to resolve because the diverging changes have spread further.
• Integration risk concentrates: the moment of integration becomes the moment of discovery. Whatever was going to break breaks all at once.
• Refactoring is blocked: developers who could improve code feel they can't because the change would conflict with branches in flight.
• Feedback delays: code that hasn't been integrated hasn't been validated against the system. Problems are discovered late.
• The team loses awareness: long branches make work invisible to teammates. Duplicate effort, conflicting decisions, and design drift all become more likely.

Common Adoption Path

Teams transitioning from long-branch models usually take it in stages:

1. Shorten branch lives: target two days, then one, then half a day.
2. Invest in CI reliability: pipeline speed, test reliability, green-trunk discipline.
3. Add feature toggles: build the toggle infrastructure that lets incomplete code merge safely.
4. Reduce review cycle time: faster PR turnaround, pair-review for small changes, async tooling for distributed teams.
5. Move toward direct trunk commits for small changes: typo fixes, single-test additions, refactors that don't change behavior.

Most teams don't end at fully direct-commit trunk. They end at "very short branches, very fast review, merges several times daily" — which preserves the benefits while keeping a lightweight checkpoint.

When Trunk-Based Is Hard

• Long-lived release branches: teams that support multiple released versions in parallel can't run pure trunk-based on the maintenance branches. The trunk-based model applies to the development trunk; the support branches are their own thing.
• Regulated environments with audit requirements: where every change requires explicit sign-off before merging, the cycle time of approval may force longer branches. The discipline still applies; the implementation gets compromised.
• Open-source contribution model: external contributors who can't be expected to merge daily produce PRs that wait. Internal trunk-based with external contribution gates is a hybrid.
• Massive teams without code ownership boundaries: thousands of engineers committing to one trunk requires significant test and CI investment. Most teams of that size split into modular trunks with clear ownership.

Common Pitfalls

• Branches sneaking longer: target is "merge daily"; reality is "merge weekly because PR review is slow." The model collapses gradually unless actively defended.
• No feature toggles: trunk-based without toggles means every incomplete feature blocks the team from merging. Either toggles or long branches; the model needs one.
• Tolerating red trunk: a broken trunk that sits red for hours destroys the model. Everyone is now committing on top of broken code; the next merge is even more dangerous.
• Heavy review overhead: required reviewers, sign-offs, gates. Each gate adds branch lifetime. Reduce process or watch the branches grow.
• Treating it as a tool change: switching git workflow without changing CI investment, testing discipline, and toggle infrastructure. The branching is the visible part of a much larger practice.

Coaching Tips

Measure Branch Age

If branches are averaging four days, you're not trunk-based. The metric tells you whether the practice is real.

Defend Green Trunk

A broken trunk blocks the team. Make fixing red trunk the highest-priority work, every time.

Invest in Toggles First

Trunk-based without feature toggles forces long branches for incomplete work. The toggle infrastructure is what makes the practice possible.

Speed Up Review

PRs that take a day to review will live a day. Reduce review cycle time aggressively — pair review, async reminders, simpler approval rules.

Watch for Drift

Branch lengths creep without anyone deciding. Make branch age visible in dashboards; surface drift early.

Pair the Practice Layers

Trunk-based, CI, toggles, test coverage, fast review — these are one practice, not five. Coaching only the branching produces failure.

Summary

Trunk-Based Development is what continuous integration actually requires. Teams that say they do CI but maintain week-long feature branches have the tooling without the practice. The discipline of merging to a single trunk multiple times a day is what produces the benefits CI promises: early integration, low merge cost, high confidence in changes.

The model is demanding. It requires test coverage, CI reliability, toggle infrastructure, and review discipline. The teams that pay that cost get speed and stability the long-branch teams never quite reach. The teams that try to skip it usually find their CI is theater — running on every merge, but with the merges so far apart that the integration story still ends in pain.

Back to Technical Practices