What Are Trunk-Based Development?
A source-control branching strategy where developers merge small, frequent changes directly into the main branch (trunk), keeping feature branches short-lived (under 1-2 days).
2-minute setup • No credit card required
What it means
Trunk-based development (TBD) is a branching model where the main branch is always in a releasable state and developers integrate their work frequently — ideally daily. Feature branches exist but are short-lived: created from main, worked on for a day or two at most, then merged back. This contrasts with Gitflow and other long-lived branch strategies where feature branches may exist for weeks. TBD is the branching strategy most strongly correlated with high DORA metrics. Google's research found that elite-performing teams are significantly more likely to use trunk-based development. The key discipline: changes must be small enough to review and merge within a day, incomplete features are hidden behind feature flags, and the main branch must always be deployable. TBD requires strong CI (every merge triggers automated tests) and good test coverage to maintain confidence in the main branch's quality.
Why Trunk-Based Development matter
Trunk-based development eliminates the biggest source of delivery delays: merge conflicts and integration pain from long-lived branches. When branches live for weeks, merging them back is painful, unpredictable, and error-prone. TBD forces small, incremental changes that are easy to review, test, and deploy. For engineering managers, adopting TBD typically reduces lead time by 50-70% because code spends less time waiting in branches. It also improves code review quality — reviewers can actually review a 100-line PR carefully, unlike a 2000-line PR from a 2-week branch. Teams using TBD report fewer production incidents because each change is small and easier to understand.
How to measure
Track branch lifespan: measure the time from branch creation to merge into main. In TBD, this should be under 2 days for most PRs. Also track: number of active branches (should be close to the number of active developers), merge conflict frequency (should be rare), and the percentage of PRs under 200 lines changed (should be above 70%). Pull this data from your git platform. If your average branch lifespan exceeds 3 days, you're not doing trunk-based development even if you call it that.
Real-world example
A team using Gitflow has 8 developers maintaining an average of 12 feature branches, each living for 5-15 days. Merge day every other Thursday takes 4-6 hours of conflict resolution. They switch to TBD: developers create branches from main, work for 4-8 hours, submit small PRs, and merge after review. Feature flags hide incomplete work. After one month: average branch lifespan drops to 6 hours, merge conflicts virtually disappear, deployment frequency goes from bi-weekly to daily, and developer satisfaction scores increase because they spend time coding instead of resolving conflicts.
Related terms
Common questions
What's the difference between trunk-based development and Gitflow?
Gitflow uses long-lived feature branches, develop branches, and release branches with a complex merge workflow. Trunk-based development uses only the main branch and short-lived feature branches (1-2 days). TBD is simpler, faster, and strongly correlated with better DORA metrics. Gitflow was designed for packaged software with infrequent releases; TBD is designed for continuous deployment.
How do you handle unfinished features in trunk-based development?
Feature flags. You merge code to main behind a flag that's turned off in production. The code exists in main but users don't see it. When the feature is complete, you turn on the flag. This decouples deployment (shipping code) from release (enabling features). LaunchDarkly, Flipper, and Unleash are popular feature flag tools.
Does trunk-based development require more testing?
It requires better testing, not necessarily more. You need reliable automated tests that run on every PR because every merge goes to main. The test suite must be fast (under 10 minutes) and not flaky. In practice, teams adopting TBD invest in their CI pipeline upfront and recoup that investment through fewer merge-related bugs and faster delivery.
Can large teams use trunk-based development?
Yes — Google, Facebook, and Microsoft use TBD with thousands of engineers. The key is strong CI infrastructure, comprehensive automated testing, and clear code ownership. Large teams often use a 'scaled trunk-based development' model where PRs still go to main but require approval from code owners for their respective areas.
Track Trunk-Based Development Automatically
Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes