Trunk-Based Development

Trunk-based development is a branching model with one rule at its center: there is a single shared branch, the trunk, and everyone commits to it constantly. A developer either commits straight to the trunk or opens a short-lived branch that lives for a few hours and merges back the same day. Branches that survive for a week or more are exactly what this model is built to avoid.

The problem it solves is merge pain. When five people each work on a private branch for two weeks, the code they all started from has drifted apart. Merging those branches at the end means resolving conflicts across thousands of lines that nobody has looked at together. This is sometimes called merge hell or integration debt. Trunk-based development attacks it by merging tiny pieces continuously, so each merge is small and the conflict surface stays near zero.

Because work lands before a feature is finished, the trunk would normally be full of half-built code. The answer is feature flags: the new code ships but stays switched off in production until it is ready. The branch becomes a runtime toggle instead of a Git branch.

A typical loop looks like this. A developer pulls the latest trunk, makes a change of maybe 50 to 200 lines, runs the tests locally, and pushes a short-lived branch. A continuous integration pipeline builds the change and runs the test suite within a few minutes. A teammate reviews it quickly, and it merges into the trunk the same day. The trunk is rebuilt and the gate keeping it green is the automated test suite.

The trunk must always be in a releasable state, which only works if the test pipeline is fast and trustworthy. Teams lean on unit tests for speed, a smaller set of integration tests, and pre-merge checks that block any commit that breaks the build. Some teams add automated merge tools or merge queues, where GitHub or GitLab serially tests each pending change against the current trunk before letting it in, so two changes that pass individually but conflict together cannot both land.

Feature flags are managed in code or in a flag service. A flag wraps the new path, for example a check like if flags.checkoutV2 is on. The code is in production from day one but dark. The team turns it on for internal users, then 1 percent of traffic, then everyone. When the rollout is done and stable, the flag and the old code path are deleted, which is a step teams often forget and which is the main source of flag clutter.

Trunk-based development is the default for teams that practice continuous integration and want to deploy often, including many times a day. It is one of the practices the DORA research program found correlates with high software delivery performance. If your goal is short lead time and frequent, low-risk releases, this is the model that supports it.

The cost is discipline and infrastructure. It does not work without a fast, reliable automated test suite, because the trunk is shared and a broken commit blocks everyone. It also requires a feature flag habit and the cleanup work that comes with flags. Teams that skip flag deletion accumulate dead toggles that make the code hard to reason about and can cause incidents when a stale flag flips.

It is a poorer fit when many of your contributors cannot be trusted to push directly, which is the classic case of large open source projects. Those projects use forks and pull requests with maintainer gatekeeping instead, sometimes called GitHub Flow or a fork-and-pull model. Trunk-based development assumes a closed team that shares ownership of one codebase.

Google runs almost its entire codebase in a single giant monorepo on one trunk, with tens of thousands of engineers committing to it. There are effectively no long-lived branches. Every change is reviewed and gated by automated tests, and unfinished features sit behind flags. Google has described this trunk-based, flag-gated style for years, including in the book Software Engineering at Google.

Compare two teams shipping the same login redesign. The branch-heavy team works for three weeks on a feature branch, then spends two days untangling merge conflicts and finds a regression that only appears once everything is combined. The trunk-based team merges a few hundred lines a day behind a flag called loginRedesign, keeps the flag off, and once the work is complete flips it on for 5 percent of users to watch the metrics. The first team integrates once, painfully; the second integrates continuously and ships when ready, with a kill switch in hand.