Most teams land on trunk-based development after one too many merges of a branch that drifted for three weeks. Developers merge small, frequent changes into one shared branch, the trunk, and the codebase stays releasable at every commit.
Small teams commit straight to trunk. Larger ones use short-lived feature branches merged through pull requests.
In DORA’s 2016 and 2017 data, teams with three or fewer active branches that merged to trunk at least once a day delivered faster and ran more stable and available systems. Teams without code freezes did better too.
What Is Trunk-Based Development?
Everyone integrates into the same branch. That branch is the trunk, also called main or mainline, and the whole point is to keep it releasable all the time. The model doesn’t tie a team to one tool, so it runs on Git as well as on centralized source control systems.
The name comes from a tree. The trunk is the thickest, longest span, and branches are shorter ones that radiate from it, as the Trunk Based Development reference site (Paul Hammant, copyright 2017 to 2020, with later additions) explains.
It isn’t a recent invention, and it doesn’t ban branches, since short-lived ones are allowed. It also isn’t the same thing as continuous integration.
DORA calls trunk-based development a required practice for continuous integration. CI adds the second half, a suite of fast automated tests that runs after every commit to trunk.
How Does Trunk-Based Development Work Day to Day?
Each developer splits work into small batches and merges into trunk at least once a day, per DORA. Branches, where they exist at all, last hours rather than weeks.
Cheap branching arrived with Git and Mercurial in the mid-2000s, according to the reference site. A Git branch that lives a few hours costs a team almost nothing to create and delete.
When the build breaks, developers stop and fix it. If the fix will take more than a few minutes, they revert the change instead (DORA).
A few numbers keep coming up in the sources:
- Every developer merges into trunk at least once a day (DORA)
- No more than 3 active branches in the repository, from DORA’s analysis of its 2016 and 2017 data
- Branch life of hours according to DORA, against a couple of days on the reference site
- 95% of Google software developers work in its single repository, with trunk-based development on top of it (Communications of the ACM, 2016)
The branch-life figures disagree. The two-day rule on the reference site is written for short-lived feature branches in larger teams, while DORA states the hours figure for the practice in general.
Small merges stay readable. Large ones hide defects from reviewers, which is why DORA pushes small batches in the first place.
Which Trunk-Based Development Style Fits Your Team Size?
Teams of up to 15 developers can commit straight to trunk. From 16 developers up, the reference site finds short-lived feature branches with pull requests more productive.
| Dimension | Direct commits to trunk | Short-lived branches with pull requests |
|---|---|---|
| Team size | Up to 15 developers | 16 or more |
| Gate before trunk | Full local build, then CI on trunk | Pull request, review, pre-merge CI |
| Branch life | None | Under about two days |
| Where it breaks | A broken build lands before CI reports | The branch outlives two days |
Direct commits to trunk
Small teams skip branches. Everyone knows what the others are working on, and the build is fast enough to run in full before every push.
If CI turns red after integration, the usual move is an immediate revert, sometimes with a short lock on trunk while it happens.
- Run the full build before every push
- Revert first, investigate after
The failure here is easy to miss. Two changes can auto-merge with no textual conflict and still break each other in meaning, like a renamed function and a new caller in another file. Only the build catches that, the reference site notes.
Short-lived feature branches with pull requests
A branch belongs to one developer, or two when they pair program. It gets merged and deleted within a couple of days, before it turns into a long-lived feature branch. Main flows into the branch to keep it current, and the branch flows into trunk only when it closes out. CI verifies the branch before the commit lands.
A slow code review process is the usual way this style falls apart. DORA reports that reviews taking hours or days push developers to batch up changes, which defeats the model.
How Do Teams Ship Unfinished Work From Trunk?
They hide it. Feature flags keep incomplete code switched off in production, and branch by abstraction lets a large change grow inside trunk behind a seam, so trunk stays deployable throughout.
Feature flags
Pete Hodgson’s article on martinfowler.com (2017 revision) calls these release toggles and says they should not stay much longer than a week or two. Product-centric ones can live longer.
Done well, feature flagging separates deployment from release. The code ships to production, and the behavior stays off until the team flips it.
The catch is that flags multiply. Each one adds a code path to test, so teams test the configuration they plan to ship plus the fall-back with the new flags off, and skip the full set of combinations (martinfowler.com).
Some teams add a removal task to the backlog the day a release toggle is created, and others set expiry dates (martinfowler.com). The reference site names forgotten flags as technical debt.
Branch by abstraction
Branch by abstraction handles a change too big for one day, such as swapping a persistence library. It is a form of code refactoring done in small commits inside trunk, so the build stays green at every step.
- Wrap the code being replaced in an abstraction and commit it.
- Write a second implementation behind the abstraction, switched off in trunk.
- Flip the switch on for the whole team and commit.
- Delete the old implementation.
- Delete the abstraction, unless unit tests benefit from keeping the seam.
ThoughtWorks used it in the Go continuous integration server to move from iBatis to Hibernate without slowing teammates or blocking a release (reference site).
It doesn’t suit teams that must support old APIs and earlier releases for more than a short period, because customers choose their own upgrade moment.
How Are Releases Cut From Trunk?
Teams release either straight from trunk or from a release branch snapshotted off it. Fast-shipping teams deploy trunk itself, and slower cadences cut a branch late and cherry-pick fixes onto it.
Teams that ship several times a day need no release branch, because changes go into trunk and deploy from there (DORA). That is the shape of continuous deployment, and bug fixes get treated like any other change.
High-throughput teams usually roll forward. Instead of a rollback in deployment, the fix lands on trunk and ships from there, per the reference site.
Teams on a planned cadence cut the release branch just in time, shortly before the release. Developers keep committing to trunk at full speed, and the branch receives no new development.
A production bug on a release branch gets fixed in this order:
- Reproduce the bug on trunk and fix it there with a test.
- Let CI verify the fix on trunk.
- Cherry-pick the commit onto the release branch.
- Let a second CI run verify it on the branch.
DORA’s diagram shows release-branch changes merged back to trunk as soon as possible. The reference site takes the opposite position. Release branches are never merged back, and fixes travel from trunk to branch only.
Trunk-first is the safer rule. Forget to port a branch-only fix back and you get a regression weeks later, the reference site warns.
The exception is a bug that can’t be reproduced on trunk. There the fix goes on the branch, and the regression risk goes up with it.
Teams can also release from a tag on trunk and skip the branch until a patch is needed, since a branch can be created retroactively from that tag.
What Does Trunk-Based Development Require to Work?
A fast automated test suite comes first, followed by a CI service that verifies every commit to trunk. Code review has to be quick, and the team needs an agreed rule for broken builds. Without these, small frequent merges only move breakage around faster.
Build speed sets the commit rate. A build of a couple of minutes keeps developers at a high pace, according to Paul Hammant’s reference site, and at 30 minutes or worse they settle into a couple of commits a day.
The same build script runs on the developer machine and in the CI service. A staged build pipeline splits it into compile, unit, service and functional steps, so a failure points at one layer.
Good builds put most of their effort into compilation and pure unit tests, the kind that touch no threads, sockets or file IO. Slower integration steps come last and stay few.
Every team bigger than three people needs a CI service, the same site argues, because nobody can guarantee that each developer ran the build before pushing. On GitHub, branch protection can block a merge until required checks pass (GitHub Docs, as of October 2026).
A build that is red all the time is the failure case. A suite that fails often, or an overnight job with a share of failures, loses most of its value, and false failures from flaky tests are common.
Trunk-Based Development vs Gitflow and GitHub Flow
Gitflow keeps two permanent branches plus release and hotfix branches, and GitHub flow works from short branches off the default branch. Trunk-based development goes further by merging to trunk daily. For continuous delivery, the last two fit. For versioned software with several releases in the wild, Gitflow still does.
| Dimension | Trunk-based development | Gitflow | GitHub flow |
|---|---|---|---|
| Permanent branches | Trunk only | master and develop | Default branch only |
| Feature branch life | Hours to a couple of days | As long as the feature takes | Until the pull request merges |
| Release handling | Tag, or short release branch off trunk | Release and hotfix branches, merged back | Merge to default branch, delete the branch |
| Best fit | Continuous delivery, frequent releases | Explicitly versioned software | Teams doing continuous delivery |
Gitflow’s author on when it fits
Vincent Driessen added a note of reflection to his original post on March 5, 2020. Web apps, he wrote, are typically delivered continuously and not rolled back, and only one version runs in the wild.
For that class of software he suggests a simpler workflow such as GitHub flow rather than shoehorning Gitflow in. For explicitly versioned software, or software with several versions in the wild, Gitflow may still fit.
A team on continuous delivery has no reason to adopt it.
Where GitHub flow overlaps
- Create a branch with a short, descriptive name.
- Make, commit and push changes on it.
- Open a pull request.
- Address review comments.
- Merge the pull request.
- Delete the branch.
GitHub uses this flow for its site policy, documentation and roadmap repositories, per GitHub Docs. The page sets no limit on branch lifetime, which is the gap trunk-based development fills with its daily-merge rule.
What the delivery metrics show
DORA’s guide, last updated January 5, 2026, lists five software delivery metrics. The original four keys grew to five, and mean time to restore became failed deployment recovery time.
Change lead time, deployment frequency and failed deployment recovery time cover throughput. Change fail rate and deployment rework rate cover instability.
DORA treats trunk-based development as a capability and not a metric, so the five numbers are the outcome to watch. Its research finds speed and stability are correlated for most teams, and top performers do well across all five.
The guide adds two cautions. Measure one application or service at a time, and never turn a metric into a target, since teams then game it.
When Does Trunk-Based Development Not Fit?
It doesn’t fit when releases are tied to long iterations, when the process rewards late integration, when several versions of the product stay supported at once, or when one repository takes commits faster than it can merge them.
| Condition | What breaks | Better move |
|---|---|---|
| Iterations of four weeks or more | Continuous delivery stays out of reach | Adopt the practices, keep release branches |
| Waterfall process | No habit of keeping the build green | Move to short iterations first |
| Several versions in the wild | Old releases need long support branches | Gitflow or release branches |
| Very high commit rate | Pushes collide, merges queue up | Merge queue, pre-merge CI |
Teams on iterations of four weeks or more can still follow the tenets and run CI, but they can’t reach continuous delivery, per the reference site. A fixed software release cycle that long is the usual cause.
Pure waterfall methodology sits further away still. The site says such teams are nowhere near the “do not break the build” habit and should move to a short-iteration agile method first.
High commit rates have their own failure. In plain Git a colleague can beat you to the push, forcing a pull, a merge and another attempt, which the reference site calls the race to push.
The site notes that GitHub made merge queue generally available in July 2023. It also says Microsoft built VFS for Git partly because of contention on busy repositories.
For a team that supports several released versions, the honest advice is to keep release branches, or use Gitflow.
How Do You Move a Team to Trunk-Based Development?
Measure before changing anything, and fix the build before touching branch policy. Do it the other way round and you’ve put frequent merges on top of a suite nobody trusts.
- Record the baseline: active branches, merge frequency, code freezes and how long reviews take to approve (the measures DORA lists).
- Speed up and stabilize the build before touching branch policy.
- Split stories into tasks that finish in hours, since anything past a couple of days pulls developers onto shared branches.
- Put work that cannot finish in a day behind a flag or an abstraction.
- Cap branch life, and review synchronously by asking a teammate when the change is ready to commit.
- Agree the broken-build rule: stop, fix or revert.
- Pilot with one team led by developers who have worked this way, then move the others.
- Check the five DORA metrics against the baseline.
Before step 5, look at code coverage on the modules that change most. Thin coverage there is where the first broken trunk will come from.
Expect resistance. DORA notes that many developers can’t imagine working in small batches, and it recommends having developers who have worked this way coach the others.
Judge the move by trend, not by a single number. DORA warns that setting a metric as a goal invites gaming, and it recommends repeating the cycle of baseline, change and check through its Quick Check, team conversations and retrospectives.
Trunk-Based Development FAQ
Is trunk-based development the same as continuous integration?
No, though they overlap. DORA calls trunk-based development a required practice for continuous integration.
A CI server watching several long-lived branches doesn’t make a team trunk-based. Martin Fowler criticized that habit in his Continuous Integration Certification post, which the reference site cites.
Does Google run its whole codebase from trunk?
Mostly. The 2016 Communications of the ACM paper says the vast majority of developers on Piper, Google’s in-house repository, work at the head of a single trunk.
Development branches are rare there. In a 2015 @Scale talk that the reference site quotes, Rachel Potvin said branches exist for releases, with cherry-picked fixes developed on trunk and pulled into the branch.
Are feature flags and feature toggles the same thing?
Yes. Pete Hodgson’s article on martinfowler.com treats feature toggles, flags, bits and flippers as synonyms for one set of techniques.
Flag is the more common term in the industry, per the reference site.
Do feature flags need a dedicated tool?
No. A flag can begin as a command-line argument, an environment variable or a line in a config file.
Runtime-switchable flags are the exception. Their state must survive restarts and reach every node, which is why the reference site points to a shared store such as Consul or etcd.
How does trunk-based development handle database schema changes?
Teams keep table-shape changes under source control and migrate existing data when columns change. The reference site lists this as a deciding factor before adoption.
For method, it points to the book Refactoring Databases and the Continuous Delivery book.
When should you delete a release branch?
Not immediately. Delete it once the release is clearly out of production, usually after releases from newer branches have gone live.
In Git, tag the released commit first, because dangling commits get garbage collected (reference site).
How to Tell the Move to Trunk-Based Development Is Working
Trunk-based development shows up first in branch age and review wait time, well before deployment frequency or change fail rate move. DORA classes its five delivery metrics as lagging indicators for delivery practices, so they confirm the change late.
A rising review wait predicts aging branches, since DORA ties slow review to batched changes and the reference site treats overdue branches as the start of long-lived ones.
The trade-off is interruption. Synchronous review pulls teammates off their own tasks, and the team must agree to put review first.
Position verified October 1, 2026, against DORA’s metrics guide, last updated January 5, 2026. A revision to DORA’s metric set would change which lagging numbers to track.
With trunk green and merges daily, the deployment pipeline is the next piece to build, because it carries each passing commit toward production.
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- Data Management Services: A Practical Guide for Growing Companies - October 21, 2026
- MongoDB Cheat Sheet - October 20, 2026
