Library→First Way: Flow→Tools & Techniques→Trunk-Based Development
Trunk-Based Development
Committing directly to main. Why long-lived branches are a form of waste and how short integration cycles keep flow moving.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
What is trunk-based development?
Trunk-based development is a source control practice where all developers integrate their work into a single shared branch — trunk, or main — at least once per day. There are no long-lived feature branches. Changes are small, frequent, and always in a deployable state.
The alternative is GitFlow or similar branch-heavy strategies where features live on separate branches for weeks. These approaches feel safer but create exactly the kind of integration risk they are designed to avoid.
Long-lived branches
Merge conflict hell on integration
Trunk-based development
Everyone commits to main. No divergence.
Why long-lived branches kill flow
Merge hell
The longer a branch lives, the further it diverges from main. A two-week-old branch may have hundreds of conflicts to resolve. Merge conflicts are pure waste — rework caused by delayed integration.
Delayed feedback
Tests only run when code is integrated. A bug introduced on day 1 of a feature branch may not be discovered until day 14 when the branch merges. It is now 14x harder to find the root cause.
Inventory buildup
Unmerged branches are inventory — finished work not yet delivered. Every day a branch sits unmerged, it accumulates holding cost and risk.
False safety
Long branches feel like isolation from risk. They are actually accumulation of risk. The longer you wait to integrate, the bigger the explosion when you do.
The practices
Trunk-based development requires discipline and enabling practices. It does not mean merging broken code to main.
Small commits
Each commit is a single logical change. Small enough to review in minutes. Big enough to mean something. Commit at least daily.
Short-lived branches
If you branch, merge within one or two days. Branches are a tool for code review, not for long-running development.
Feature flags
Ship incomplete features behind a flag. The code is in main, deployed to production, but invisible to users until you flip the switch.
Feature flags
The most common objection to trunk-based development: what if the feature is not ready? Feature flags answer this. A feature flag is a conditional in the code that gates a feature by configuration, not by branch.
// Feature flag — deployed to prod, not yet visible
if (featureFlags.newCheckout) {
return <NewCheckoutFlow />
}
return <LegacyCheckout />
This decouples deploy from release. The code ships continuously. The feature is revealed to users on your schedule, not your branch's schedule.
DORA research findings
DORA's multi-year research across thousands of teams identifies trunk-based development as one of the strongest predictors of high software delivery performance. Teams that practice trunk-based development have:
5x
more frequent deployments
440x
faster lead time for changes
2x
lower change failure rate
DORA found that trunk-based development — along with continuous integration and deployment automation — forms a cluster of practices that together predict elite performance. No single practice works in isolation.
Further reading
DevOps Handbook
Chapter 9: Enable and Practice Continuous Integration. Trunk-based development as the enabling practice for CI.
DORA State of DevOps Research
2019 and 2023 reports: trunk-based development identified as a key capability of elite performers.
trunkbaseddevelopment.com
The comprehensive reference site maintained by Paul Hammant. Patterns, anti-patterns, and case studies.
Continuous Delivery — Humble & Farley
Chapter 14: Advanced Version Control. The full treatment of branching strategies and trunk-based approaches.