Trunk-Based Development
A source-control practice in which all developers commit small changes to a single shared branch (trunk/main) at least daily, using feature flags rather than long-lived branches to manage in-progress work.
Definition
Trunk-Based Development (TBD) is a source-control workflow in which every developer integrates small, self-contained changes into a single shared branch — trunk or main — at least once per day. Long-lived feature branches are avoided; in-progress work that cannot yet be released is hidden behind feature flags. TBD is the branching model that makes true continuous integration and continuous deployment possible.
Why It Exists
The alternative — GitFlow-style long-lived branches — pushes integration to the end of a feature. Merge conflicts compound, refactors get abandoned because "that will break Sarah's branch," and release trains slow to a crawl. The 2023 DORA State of DevOps report continues to show trunk-based teams outperforming feature-branch teams on deployment frequency, lead time and change-failure rate by wide margins. TBD is not a matter of taste; the evidence is consistent across a decade of research.
The Core Rules
- One long-lived branch — trunk. Release branches, if used, live for hours to days, not weeks.
- Every developer integrates to trunk at least once per day.
- Trunk must always be releasable — broken builds are the number-one priority.
- In-progress features hide behind feature flags until they are ready.
- Small commits — a few hundred lines at most.
- Every commit runs the full CI pipeline before merge.
- Peer review happens in minutes, not days.
Real-World Example
A payments platform of 140 engineers moved from GitFlow to trunk-based over a 12-week transition. Before the change: 2.3 deploys per week, 6-hour average PR review time, and a 22% rollback rate. During the transition the team invested in three things — a fast CI pipeline (under 12 minutes green), a feature-flag service, and a "trunk is sacred" incident policy that pulled the whole team onto any broken build. Six months in: 47 deploys per week, 40-minute average review time, and a 6% rollback rate. The engineers who resisted loudest at the start became the most vocal advocates — mostly because the merge-hell weekends had disappeared.
Practical Lessons Learned
- Fast CI is the price of entry. Under 10 minutes green is workable; over 30 minutes and the discipline collapses because developers stop trusting the pipeline.
- Feature flags are non-negotiable. Without them, TBD becomes "commit half-done work and hope."
- Small commits are a skill, not a rule. Teach the mechanics — extract-refactor-then-add — before you insist on the outcome.
- Peer review shrinks to minutes. Reviewers reject monster PRs on principle and the culture rebuilds itself around small change.
- "Trunk is sacred" needs teeth. If a broken trunk is normal, the model has already failed.
Common Mistakes
- Adopting trunk-based without investing in CI speed — the model collapses within weeks.
- Half-adopting — some teams on trunk, some on GitFlow, sharing a repo. Everyone loses.
- No feature-flag infrastructure, so developers keep secret branches on their laptops and integrate weekly.
- Treating trunk breakage as normal — once tolerated, it becomes routine within a month.
- Requiring lengthy manual QA before every merge — TBD assumes automated test coverage is the gate.
- Reviewers who "gather feedback" over three days instead of reviewing within an hour.
- Flag debt — feature flags added and never removed, leaving a codebase of dead conditional paths.
Expert Tips
- Publish a flag lifecycle. Every flag has an owner and a retirement date; run a monthly flag-clean-up sprint.
- Measure lead time weekly. Commit to production. The number gets shorter when TBD is working and longer when it isn't.
- Split the code for the change first. Refactor to a place where the change is small, then make the change. It is faster than it looks.
- Pair on the merge, not on the code. A five-minute pair review at merge time is worth more than an hour of async comments.
- Roll back rather than roll forward. When trunk breaks, revert first, diagnose second. Optimising for a green trunk is optimising for team throughput.
Key Takeaways
- One long-lived branch, integrated to daily, kept releasable at all times.
- Feature flags carry the in-progress work; long branches do not exist.
- Fast CI and small commits are the enabling conditions, not optional extras.
- Trunk breakage is a whole-team incident, not one developer's problem.
- Feature flags carry a maintenance cost — retire them on a published cadence.
Related Concepts
Interlocks with Continuous Integration, Feature Flags, Blue-Green Deployment, Canary Release, and DevOps. Adoption playbooks at PMMilestone.org.
Frequently Asked Questions
What is trunk-based development?
A source-control workflow where all developers commit small, self-contained changes to a single shared branch (trunk or main) at least once per day. In-progress work is hidden behind feature flags rather than kept on long-lived branches.How is it different from GitFlow?
GitFlow relies on long-lived develop, release and feature branches, with integration happening at the end. Trunk-based collapses all of that into a single branch and pushes integration to the smallest possible interval — daily, ideally more often.Doesn't this risk broken builds?
Only if the CI pipeline is slow or coverage is poor. In a mature TBD setup, every commit runs the full pipeline before merge, and a broken trunk is treated as a team-wide incident that gets fixed within minutes.How do you release half-done features?
You don't. In-progress features are gated behind feature flags — the code ships to production but the flag stays off until the feature is complete, at which point the flag is turned on for a subset of users or all users.Is trunk-based development compatible with pull requests?
Yes — short-lived PRs (hours, not days) are common. The rule is not to avoid review; it is to avoid long-lived branches. A PR merged same-day is fully within the model.Does TBD work for regulated industries?
Yes, provided the audit trail requirements are satisfied by commit history and CI evidence. Financial services, health tech and defence teams have all moved to trunk-based; the compliance argument is usually a symptom of unfamiliarity, not a genuine barrier.What is the biggest mistake?
Adopting the branching model without the enabling infrastructure — fast CI, feature flags, and a shared commitment that trunk is always releasable. Half-adopted TBD is worse than staying on GitFlow.What is a common misconception about Trunk-Based Development?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.Which related encyclopedia entries should I read alongside Trunk-Based Development?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.How does Dr. Hassan Eliwa's research treat Trunk-Based Development?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Trunk-Based Development is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.How is Trunk-Based Development defined on PMMilestone Research & Insights?
A source-control practice in which all developers commit small changes to a single shared branch (trunk/main) at least daily, using feature flags rather than long-lived branches to manage in-progress work. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.
People also ask
Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.
Which calculator on PMMilestone.org applies here?
The integrated EVM workbook covers most cost-schedule diagnostics. EVM Calculator ↗
Where is this in the glossary?
Quick-lookup definitions across 1,200+ PM terms. PM Glossary on PMMilestone.org ↗
Which learning track covers this end-to-end?
Structured tracks from beginner planner to programme controls director. Project Controls Academy ↗
Which book goes deeper than this entry?
Practitioner field handbooks with worked numerical examples. Books & Publications ↗
Related Entries
More in IT / Agile
- Letter FFeature Team
A long-lived, cross-functional, cross-component team that delivers end-to-end customer-visible features — as opposed to a component team responsible for a single technical layer.
- Letter PPI Planning
Program Increment Planning — the cadence-based, face-to-face event in SAFe where all teams on an Agile Release Train commit to a set of objectives for the next 8–12 week increment.
- Letter RRunbook
A written, step-by-step operational procedure that tells an on-call engineer exactly how to detect, diagnose and remediate a specific class of incident on a specific system.
- Letter SService Level Indicator (SLI)
A quantitative measurement of a service's behaviour — such as request success rate or latency at the 99th percentile — that expresses reliability in numbers the users actually experience.
Further reading on PMMilestone.org
Curated companion resources hosted on the flagship platform, PMMilestone.org.
- For practitioners who want to go deeper, the Project Controls Academy.
- Engineers researching this topic typically continue with the Books & Publications.
- A practical companion to this entry is the EVM Calculator.
- Closely related on the flagship platform is the Schedule Health Checker.
- Useful alongside this article is the PMMilestone.org knowledge hub.