Trunk based development is a source control practice where every developer merges their work into a single shared branch, usually called main or trunk, at least once a day, rather than working for weeks on long-lived feature branches. In practice, this means small commits, frequent integration, and code that is protected behind feature flags when it is not ready for users yet. The branch itself stays close to a releasable state most of the time, because nobody is allowed to let their changes drift far from it. Teams that adopt this model tend to write smaller pull requests almost by necessity, since a change that takes three weeks to build cannot realistically be merged daily.
The reason trunk based development exists is that long-lived branches create a specific and expensive kind of pain: merge conflicts that compound over time, integration bugs that surface only when two large bodies of work collide, and a growing gap between what is in a branch and what is actually running in production. Teams using Git flow style workflows with release branches and long feature branches often discover that the final merge, the one that was supposed to be routine, becomes a multi-day exercise in conflict resolution and re-testing. Trunk based development solves this by making integration a non-event. If you merge every day, there is never enough accumulated drift for a merge to become an ordeal.
What distinguishes trunk based development from just "using Git" is the discipline around branch lifetime and the use of feature flags to decouple deployment from release. A feature branch in this model lives for hours, not weeks. Work that isn't finished gets merged anyway, hidden behind a flag, and turned on later once it's complete and tested. This is a different mental model from branching strategies where a branch represents a feature until that feature is fully done. It also depends on a testing and CI setup that can catch problems fast, because you are relying on automation, not a human doing a final review of a giant diff, to keep trunk healthy.
By 2026, trunk based development is the default recommendation from most engineering leaders who have scaled a team past a handful of engineers, and it is baked into the DORA metrics research as a strong predictor of high performance in software delivery. Companies running continuous deployment pipelines, where code can go to production dozens of times a day, more or less require this approach because long-lived branches are incompatible with that cadence. Tooling has caught up too. Feature flag platforms, better CI systems, and monorepo tooling all make trunk based development easier to run at scale than it was a decade ago, when it was mostly associated with a small number of large tech companies.
This page covers why trunk based development exists, how it differs from Git flow and other branching models, the role feature flags play in making it work, where it fits and where it can struggle, and how a team actually makes the switch. The durable idea underneath all of it is simple: the longer code sits unintegrated, the more expensive integration becomes, and the way to keep that cost low is to integrate constantly. Understanding that lets a team diagnose why their releases feel painful and decide whether the fix is a new branching policy, not more process around the old one.
Git flow, popularized in the early 2010s, organizes work around develop branches, release branches, and long-lived feature branches that might live for weeks. It made sense for a specific era of software delivery, one dominated by scheduled releases, often quarterly or monthly, where you needed a clear structure for what was going into the next release and what wasn't. The problem is that this structure creates distance. A feature branch that has been alive for three weeks has drifted from main in ways nobody has fully tracked, and merging it back is where all the deferred risk shows up at once.
Trunk based development inverts the assumption. Instead of isolating work until it's "done" and then integrating, you integrate constantly and use other mechanisms, mainly feature flags and careful code review, to control what users actually see. The branch lifetime for any given change is measured in hours. This does not mean there is no code review or no quality gate. It means the unit of review is small enough that a reviewer can actually reason about it, and the unit of integration is small enough that if something breaks, it's obvious which change caused it.
The practical difference shows up most clearly at release time. In a Git flow shop, release day is often when problems appear, because that is when large chunks of previously separate work finally meet. In a trunk based shop, integration problems get caught in small doses, every day, by CI and by whoever merges next. This is a classic case of trading a large, rare cost for a small, constant one, and the small constant cost is almost always cheaper in aggregate because problems are diagnosed while the context is still fresh.
It's worth being honest that Git flow still has valid use cases, particularly for software shipped as discrete versioned releases to customers who install it themselves, like packaged enterprise software or firmware. Trunk based development assumes you control the deployment target, which is true for most SaaS products and internal tools, but not universally true. The choice between the two isn't a matter of one being modern and one being outdated, it's a matter of which deployment model you actually have.
Feature flags, sometimes called feature toggles, are the mechanism that makes trunk based development viable for anything beyond trivial changes. A feature flag is a conditional check in the code that determines whether a given piece of functionality is active, and it can be controlled at runtime without a new deployment. This is what allows a team to merge unfinished work into trunk: the code exists and is deployed, but it is switched off until it's ready.
Without feature flags, trunk based development would require every merged change to be fully complete and user-ready, which is unrealistic for anything larger than a small fix. A checkout flow redesign, for example, might take three weeks of actual engineering work. Under trunk based development with feature flags, that work gets merged in small increments daily, each piece behind a flag, and the flag gets flipped on only once the whole thing is tested and ready. Users see nothing until the team is confident, but the code has been integrating with the rest of the system the entire time.
Feature flags also enable a few practices that pure branching cannot: gradual rollouts to a percentage of users, kill switches for turning off a problematic feature without a rollback deployment, and A/B testing where two flag states run simultaneously for different user segments. These uses go beyond just supporting trunk based development, but they share the same underlying mechanism, and teams that adopt trunk based development often end up building general-purpose flag infrastructure that pays off in these other ways too.
The tradeoff is that flags accumulate. A codebase with years of trunk based development and no discipline around retiring flags ends up with dozens of conditional branches nobody remembers the purpose of, some of which are permanently on, some permanently off, cluttering the code and creating their own testing surface. Mature teams treat flag cleanup as a routine task, not an afterthought, usually removing a flag within weeks of a feature being fully rolled out and stable.
Trunk based development does not work without a CI system that runs fast, reliable automated tests on every merge. This is not optional infrastructure sitting alongside the practice, it is the thing that makes daily merging safe. If a broken change can sit in trunk for hours before anyone notices, then trunk is no longer the reliable, close-to-releasable branch the whole model depends on. The feedback loop needs to be fast enough that a developer knows within minutes, not days, whether their merge caused a problem.
This has real infrastructure implications. Teams need a test suite that runs quickly, often meaning parallelized tests, a mix of fast unit tests and a smaller number of slower integration tests, and enough test coverage that a green build is actually meaningful. A CI pipeline that takes 45 minutes to run discourages the exact behavior trunk based development requires, because developers start batching changes to avoid running the pipeline repeatedly, which quietly reintroduces the long-lived branch problem trunk based development was meant to solve.
There is also a cultural dimension. In trunk based development, a broken trunk is treated as an emergency that the whole team stops to fix, not a background task someone gets to eventually. This is sometimes called "stop the line" culture, borrowed from manufacturing, where anyone can and should halt the process when something is clearly wrong rather than continuing to build on top of a known-broken foundation. Teams that don't adopt this norm often end up with a trunk that is nominally shared but practically unreliable, which undermines the entire premise.
Pull request size discipline follows from this too. Small pull requests are easier and faster to review, easier for CI to validate quickly, and easier to revert cleanly if something does go wrong. Teams practicing trunk based development well tend to aim for pull requests that can be reviewed in under 30 minutes and merged within a day of being opened, and reviewing a colleague's small pull request typically takes priority over most other work, since an unreviewed change blocks that person's whole day rather than just a small part of it. This isn't an arbitrary rule, it's a direct consequence of wanting the branch to never drift far from trunk.
Some teams lean on pair or mob programming specifically because it collapses the review step into the act of writing the code itself, since much of what a reviewer would otherwise need to check has already been discussed and agreed on in real time. This isn't a requirement of trunk based development, plenty of teams do it successfully with traditional asynchronous review, but it addresses the same underlying goal from a different angle, keeping the time between writing code and getting it safely into trunk as short as possible. Trunk visibility tools, dashboards showing build health, recent merges, and how often trunk breaks, also become worth investing in as more people merge more often, since that aggregate picture is exactly the information a team needs to know whether its practice is actually healthy or quietly degrading.
Trunk based development fits naturally with teams practicing continuous delivery or continuous deployment, where the deployment pipeline can push to production frequently and safely. It also fits well with cloud-native, SaaS-style products where the team controls exactly what version of the software is running at any time, since there's no need to maintain multiple released versions in parallel for different customers. Startups and mid-size engineering teams, in particular, often find it a natural fit because the coordination overhead of more complex branching models isn't justified by their scale or their release model.
It fits less naturally with software that ships as discrete, versioned releases installed by the customer, such as embedded firmware, desktop software with infrequent update cycles, or enterprise software where customers explicitly choose when to upgrade. In these cases, a team may genuinely need to maintain several release branches in parallel, backporting fixes to older versions still in use. Trunk based development doesn't forbid this, but it requires additional branching structure layered on top, usually short-lived release branches cut from trunk at a point in time, which is a hybrid rather than a pure trunk model.
It also struggles in teams without strong test automation or CI discipline. Trying to adopt trunk based development on top of a flaky, slow, or nonexistent test suite tends to produce a trunk that is broken often, which erodes trust in the whole approach faster than any technical argument against it. In these cases, the actual prerequisite work is investing in testing and CI, and the branching strategy conversation is secondary.
Very large codebases with many, often loosely coordinated teams sometimes run into scaling questions, particularly around code ownership and review load on a single shared trunk. Large organizations that do this successfully, such as companies running monorepos with thousands of engineers, invest heavily in tooling, like automated code owners, sharded CI, and strict pre-merge validation, to make a single trunk workable at that scale. Smaller teams get the benefits of trunk based development without needing nearly as much of that supporting infrastructure.
The first real step in adopting trunk based development is usually not a branching policy change at all, it's an honest audit of the test suite and CI pipeline. If merges take an hour to validate, or the test suite is flaky enough that a red build doesn't reliably mean something is broken, fix that first. Teams that skip this step and jump straight to "everyone merge to main daily" tend to end up with a chaotic, unreliable trunk that turns people back toward branching for safety, which defeats the purpose.
Next comes building feature flag infrastructure, even a simple one. It doesn't need to be a sophisticated third-party platform on day one, a basic configuration-driven toggle system is enough to start. The important part is establishing the habit: when work isn't finished, it still merges, just hidden. This habit is the single biggest behavioral shift for engineers coming from a long-branch culture, where the instinct is to keep work private until it feels complete.
Pull request size needs active management early on. Teams transitioning to trunk based development often benefit from an explicit, if informal, target: changes small enough to review in well under an hour. This sometimes means intentionally decomposing a larger feature into a sequence of smaller, individually mergeable steps, which is a skill in itself and takes practice. Tech leads modeling this behavior in their own pull requests tends to spread the norm faster than a written policy does.
Decomposing larger features into small, safely mergeable steps is worth teaching explicitly rather than assuming engineers will figure it out on their own. Common techniques include building new functionality behind a flag from the first commit, adding new data fields or schema changes in a separate, earlier step before the code that uses them, and building out one thin vertical slice of a feature completely before expanding it, rather than building every layer of a large feature partway at once. None of these techniques are unique to trunk based development, but they become essential skills once daily merging is the norm rather than an occasional nice-to-have.
Finally, teams should expect an adjustment period where trunk breaks more than it used to, simply because more people are merging more often. This is not a sign the practice is failing, it's a sign the safety net (fast CI, small merges, quick fixes) needs tightening. Treating early breakages as a call to invest further in automation, rather than a reason to retreat to long branches, is what determines whether the transition sticks. Most teams that give it a genuine few months, rather than judging it after the first rocky week, find the daily merge rhythm becomes just how the team works.
It's also worth naming the metrics a team can use to tell whether the transition is actually working, rather than relying purely on gut feel. Average pull request age, the time between opening a change and merging it, is a good leading indicator, and it should trend down over the first few months of adoption. Trunk breakage frequency and time-to-recovery are good lagging indicators, since even a healthy trunk based setup will break sometimes, what matters is whether the team notices quickly and fixes it quickly, rather than whether breakage happens at all. Teams that track these numbers, even informally, tend to have much more productive conversations about whether the practice needs adjusting than teams relying only on impressions of whether things "feel" smoother.
Leadership support matters more than it might seem for a change that looks, on its surface, like a purely technical policy decision. Engineers coming from a long-branch culture often feel real anxiety about merging unfinished work into a shared branch, even behind a flag, because it runs counter to years of habit built around keeping work private until it's polished. Managers and tech leads who actively model the practice themselves, and who explicitly frame early mistakes during the transition as expected rather than as a sign someone did something wrong, tend to see the cultural shift take hold considerably faster than teams where the policy is handed down without that visible backing.
Trunk based development is a version control practice where developers integrate their changes into a single shared branch, usually called main or trunk, at least once a day rather than isolating work on long-lived feature branches, using feature flags to keep unfinished work hidden from users until it's ready.
Git flow relies on long-lived develop, feature, and release branches that can exist for weeks before merging, while trunk based development keeps branch lifetimes to hours and integrates constantly, trading a large infrequent merge cost for a small constant one.
For anything beyond small, quick changes, yes. Feature flags let a team merge incomplete work into trunk safely by keeping it switched off until it's fully built and tested, which is what makes daily merging practical for larger features.
It requires fast, reliable automated testing that runs on every merge, ideally completing in minutes rather than hours, because the entire model depends on developers getting quick, trustworthy feedback about whether their change broke anything.
It can, usually as a hybrid where short-lived release branches are cut from trunk at a point in time for a given version, while day-to-day development still happens through frequent trunk merges. Pure trunk based development assumes you control the deployed version, which isn't always true for shipped software.
No, merging to trunk and deploying to production are separate decisions. A team can merge to trunk multiple times a day while still deploying on a weekly schedule, feature flags and deployment pipelines give you control over what actually reaches users.
The most common failure mode is adopting the branching policy without first fixing test automation and CI speed, which produces a trunk that breaks often and erodes trust in the practice before it has a chance to prove itself.
Small enough for a reviewer to reason about clearly, often targeted at something reviewable in under 30 minutes. This usually means decomposing larger features into a sequence of smaller, individually mergeable changes rather than one large diff.
No, it's arguably easier for smaller teams to adopt, since there's less coordination overhead and fewer conflicting streams of work. Large organizations that use it successfully typically invest heavily in extra tooling, like automated code ownership and sharded CI, to make a single trunk scale.
