For most of the last decade, the default way teams organised their code was to cut a branch, disappear into it for a week or two, and merge it back when the feature was done. That model has quietly lost the argument. By 2025 the industry had largely settled on trunk-based development for high-performing teams (TechSaaS, 2025), and the older alternative, GitFlow, has steadily lost popularity in its favour (Assembla, 2025).
This is not a fringe opinion. Atlassian now labels Git Flow a legacy workflow, its own creator recommends against it for teams doing continuous delivery, and Dave Farley, who co-wrote the book on continuous delivery, calls it fundamentally incompatible with continuous integration (DEV, 2026). When the people who defined a practice start steering teams away from it, it is worth understanding why.
This post is about what trunk-based development actually is, why long-lived branches became a liability, what the research says, and the honest cases where the older model still fits. No code, just the shift and the reasoning behind it.
What trunk-based development actually is
The idea is deliberately simple. Every developer commits to a single shared branch, the trunk or main, at least once a day, using short-lived branches that live for hours rather than weeks and are merged back almost immediately (codewithmukesh, 2026). The whole goal is to minimise complexity by shortening the lifespan of each branch to under a day (LaunchDarkly, 2026).
The research that underpins it is even more concrete about the discipline: teams perform better when they keep three or fewer active branches in the repository, merge to trunk at least once a day, and avoid code freezes and long integration phases (DORA). Work in small batches, integrate constantly, and never let a branch drift.
The nuance is that this is a change in habit more than in tooling. Most engineers who try it find the daily workflow simpler than what they were doing before, but it does require unlearning the instinct to hoard changes on a private branch until they feel finished.
The problem it replaces: divergence that compounds
The cost of a long-lived branch is not felt while it is open, it is felt at the merge. The longer a branch lives, the further it drifts from main as other people ship, and the reconciliation at the end becomes a project of its own. The numbers are stark: Microsoft's internal research found that teams going more than three days without merging faced conflict-resolution times twelve times longer than teams that merged daily, because divergence compounds (GitKraken, 2026).
There is a design mismatch underneath it too. GitFlow was built in 2010 for boxed software shipped on monthly release cycles, and in a continuous-delivery world every release branch and hotfix branch becomes a barrier between the code and its users, an active liability rather than a safeguard (CodePulse, 2026).
The nuance is that the pain is easy to misattribute. When a giant merge breaks main and someone spends a day debugging code they did not write, it looks like a bad week, not a bad workflow. The merge week is the symptom, and the long-lived branch is the cause.
Why the research keeps pointing the same way
The link between trunk-based development and elite performance is one of the most durable findings in the field. DORA's research has consistently shown that high-performing organisations work in small batches and merge into a shared trunk frequently, and that elite performers who meet their reliability targets are 2.3 times more likely to use trunk-based development, while low performers are more likely to use long-lived branches and delay merging (LaunchDarkly, 2026).
More recent analysis points the same way, with elite performers reported as 3.1 times more likely to use trunk-based development than low performers (CodePulse, 2026). The mechanism is not mysterious: small, frequent merges mean smaller diffs, faster feedback, and a codebase that stays releasable, which is exactly what lead time, deployment frequency, and change failure rate reward.
The nuance is that correlation is not a magic switch. Trunk-based development is a marker of teams that also have strong testing and fast pipelines, and adopting the branching habit without those foundations just moves the pain around rather than removing it.
Feature flags are what make it safe
The obvious objection to merging constantly is that features are not always finished. The answer is to decouple deploying code from releasing it. With feature flags, incomplete features can merge to main without affecting users, and the release happens by flipping a flag rather than merging a branch, which removes the very thing long-lived branches existed to protect against (GitKraken, 2026).
This is why flags and trunk-based development are almost always discussed together: incomplete work is hidden from users but never hidden from continuous integration, so it is still built and tested on every commit (codewithmukesh, 2026). The half-built feature lives on main, safely dark, instead of drifting on a branch.
What it costs, and where the old model still fits
Trunk-based development is not free. It demands genuine continuous-integration discipline, a fast and reliable pipeline that runs on every commit, because a broken trunk now blocks everyone, and it asks developers to make a real cultural shift toward working incrementally (DEV, 2026). A common blocker is a heavyweight code-review process, because when reviews take hours or days, developers batch up large changes to avoid the friction, which quietly defeats the whole model (DORA).
And the older model has not vanished for good reason. GitFlow still makes sense for mobile apps with app-store releases, versioned or boxed software that must support several releases at once, and compliance-heavy environments that require formal, documented approval trails (Ilir Ivezaj, 2026). The point is not that branches are evil, it is that long-lived ones are a poor fit for software shipped continuously.
The nuance is to match the model to the delivery reality rather than to habit. A team deploying to production several times a day and still running week-long feature branches is fighting its own workflow; a team shipping a signed mobile binary once a month is not.
The part worth sitting with
The reason this shift matters is that a branching model is not a neutral preference, it is the transmission of an engineering team, and it sets a ceiling on how fast and how safely code can move. Long-lived branches feel productive from the inside, because the work is visibly piling up, but the bill arrives all at once at the merge, in conflicts, in bugs found weeks too late, and in releases that turn into events. Trunk-based development spreads that cost out until it nearly disappears: small changes, merged daily, integrated continuously, with feature flags keeping the unfinished parts safely out of sight. It asks for real discipline in return, a fast pipeline and a light review process, and it is not the right fit for every kind of software. But for anything shipped continuously, the industry has already voted, the creators of the old model have moved on, and the research has been pointing the same direction for years. The long-lived branch had a good run. It is simply no longer how fast teams build.
Author note
I am Manjunaathaa, an Associate DevOps Engineer at Frigga Cloud Labs. I work across AWS, GCP, and Azure daily, with GitHub Actions as my deployment backbone. My focus is Proactive Resilience, and branching is where resilience quietly begins, because a codebase that integrates every day is one that can never surprise the team with a two-week merge during an incident. Every practice in this post is something I actually run in production, not something I read about. What convinced me was watching the cost curve first-hand: a long-lived branch feels cheap right up to the merge, where it becomes the most expensive hour of the sprint, and trunk-based development simply refuses to let that debt accumulate. I merge to main most days, keep changes small enough to review in minutes, and hide anything unfinished behind a flag. It is less heroic and far more predictable, which is exactly what resilience is supposed to feel like. Let's connect on LinkedIn → Manjunaathaa.