Trunk-based development
trungk bayst deh-VEL-up-ment
A branching strategy where developers commit directly to main (trunk) or use very short-lived branches.
Trunk-based development (TBD) is a branching strategy where everyone commits to a single branch: main (also called trunk). Feature branches, if used at all, live for hours, not days or weeks. The idea is radical simplicity: one branch, frequent commits, continuous integration.
Google, Facebook, and Microsoft use trunk-based development at scale. Google has a single monorepo with 25,000 engineers committing to one branch. They make it work with strong CI, automated testing, feature flags, and code review at the commit level. The result is that code is always integrated, merge conflicts are rare, and deployability is continuous.
Trunk-based development is the opposite of Git Flow, which uses long-lived branches for features, releases, and hotfixes. TBD advocates argue that long-lived branches create integration risk. The longer a branch lives, the more it diverges from trunk, and the harder it is to merge. By committing to trunk frequently (multiple times per day), integration problems surface immediately when they are small and easy to fix.
Examples
A team adopts trunk-based development.
Previously, feature branches lived for 1-3 weeks. Merge conflicts were a weekly problem. The team switches to trunk-based: developers commit to main multiple times per day behind feature flags. Merge conflicts drop to near zero. The CI pipeline runs on every commit. If a commit breaks the build, it is caught within minutes and fixed immediately because the change is small.
A developer uses a short-lived branch in trunk-based development.
The developer creates a branch at 9am, makes the change, opens a PR at 10am, gets a review by 11am, and merges by noon. The branch lives for 3 hours. This is still considered trunk-based development because the branch is so short-lived that divergence is negligible. The PR exists for code review purposes, not for long-term isolation.
A company transitions from Git Flow to trunk-based development.
The team previously maintained develop, release, and feature branches. Release preparation took a week of merge conflict resolution and stabilization. After switching to trunk-based with feature flags, there is no release branch. Any commit to main is deployable. Release preparation drops from a week to minutes. The team deploys 8 times per day instead of once every two weeks.
In practice
Read more on the blog
Frequently asked questions
Is trunk-based development the same as committing directly to main?
Not necessarily. In pure trunk-based development, yes, developers commit directly to main. In the more common 'scaled' variant, developers use very short-lived branches (hours, not days) with pull requests for review, then merge quickly. Both are trunk-based because the branch divergence is minimal. The key principle is that no branch lives long enough to create meaningful integration risk.
How do you do trunk-based development without breaking main?
Three things: strong CI that runs on every commit, feature flags that hide incomplete work, and small commits. If every commit is small and tested, the risk of breaking main is low. If a commit does break main, it is caught in minutes by CI and easily reverted because the change is small. Feature flags let you merge incomplete features without exposing them to users. The discipline is: main is always deployable.
Related terms
A separate branch in version control where a developer builds a new feature before merging it to main.
A branching model with long-lived develop and release branches alongside feature branches.
A parallel version of the code that lets developers work on changes without affecting the main codebase.
Continuous integration and continuous deployment: automating code testing and delivery to production.
Configuration toggles that control which features are active in production without deploying new code.

Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.