Google has over 35,000 developers committing to one single branch. No long-lived feature branches. No merge day. Just one trunk that everybody pushes to, multiple times a day. So what is trunk based development, and why do the highest-performing engineering teams treat it as non-negotiable?
Trunk based development is a version control strategy where developers merge small, frequent updates into a shared main branch instead of isolating work on separate feature branches for weeks at a time.
This article breaks down how the model works, how it compares to GitFlow, where feature flags fit in, what problems to expect, and how to adopt it without wrecking your team’s workflow.
What Is Trunk Based Development
Trunk based development is a source control management practice where developers merge small, frequent code changes into a single shared branch called the “trunk” or main. There are no long-lived feature branches. No week-long isolation. Just one branch that everyone commits to, multiple times a day.
The idea has been around since the mid-1990s, rooted in extreme programming practices and later codified through the continuous delivery movement. Jez Humble and Dave Farley made the case for it in their 2010 book Continuous Delivery, and it has since become the default branching model for high-performing engineering teams.
Google runs trunk based development at a scale most teams will never touch. Their monorepo holds over 2 billion lines of code, supports more than 25,000 developers, and processes roughly 40,000 commits per day. Meta and Microsoft operate similar models.
The 2024 DORA Accelerate State of DevOps Report, drawing on feedback from over 39,000 professionals, continues to identify trunk based development as a required practice for continuous integration. Only 19% of teams reached elite performance levels in 2024, and those teams deploy on demand with recovery times under an hour.
The core principle is dead simple. Keep branches short. Merge fast. Fix forward. And never let the trunk break.
How Trunk Based Development Works
Developers start by pulling the latest version of the trunk. They make a small change (a bug fix, a refactored function, a piece of a larger feature) and push it back to main. The whole cycle might take a few hours. Sometimes less.
Every commit to the trunk triggers a build pipeline. Automated tests run. If anything breaks, the team knows immediately. There’s no “merge day,” no integration sprint, no three-day conflict resolution session.
Axify research found that elite teams have 182x more deployments per year and 2,293x faster deployment recovery times compared to low performers. Smaller batches and frequent feedback loops are the mechanism behind those numbers.
Short-Lived Feature Branches vs. Direct Commits
Two sub-patterns exist within this model, and both are valid.
Direct-to-trunk commits: Developers push straight to main. Works best for very small teams (two to five people) where trust and communication are tight.
Short-lived branches: A developer opens a branch, works for a few hours, gets a code review via pull request, and merges. The branch lives less than a day.
DORA’s research is clear on this. Branches in trunk based development should last no more than a few hours. Anything beyond a day starts to erode the benefits. The boundary is branch lifespan, not whether branches exist at all.
Tools like GitHub pull requests fit perfectly here, as long as the branch merges fast. PostHog, for example, merged 4,344 pull requests to their main app in 2023 using exactly this approach.
Trunk Based Development vs. GitFlow
GitFlow, popularized by Vincent Driessen, uses multiple long-lived branches: develop, release, hotfix, and feature. Trunk based development uses one.
That single structural difference creates a cascade of practical consequences.
| Aspect | Trunk Based Development | GitFlow |
|---|---|---|
| Branch count | One main branch | Multiple long-lived branches |
| Merge frequency | Multiple times daily | End of feature cycle |
| Merge complexity | Low (small diffs) | High (large diffs, conflicts) |
| Release model | Continuous delivery | Scheduled releases |
| Best fit | SaaS, frequent deploys | Packaged software, formal releases |
Where GitFlow Still Works
Look, GitFlow isn’t dead. It still makes sense for teams shipping packaged software with formal release cycles. If you’re building desktop applications or maintaining multiple production versions simultaneously, the structured branching model gives you version isolation that trunk based development doesn’t.
But for SaaS products, web apps, and teams practicing continuous deployment, GitFlow introduces friction that compounds with team size. Atlassian’s own documentation acknowledges that long-lived feature branches have a higher risk of deviating from the trunk and introducing conflicting updates.
Why Teams Switch
Merge conflicts are the usual breaking point. When feature branches live for weeks, the diff between your branch and main grows every single day. By the time you’re ready to merge, you’re resolving conflicts that shouldn’t exist.
AWS prescriptive guidance notes that trunk based development reduces this problem by integrating changes continuously, keeping a cleaner codebase and cutting the time spent on conflict resolution.
The 2024 State of CI/CD Report from the CD Foundation, based on data from over 150,000 respondents, found a strong correlation between the number of DevOps technologies used (including CI/CD tools) and a team’s likelihood of being a top performer. Teams that invest in trunk based development alongside CI tooling consistently score higher across all DORA metrics.
Feature Flags in Trunk Based Development
Here’s the thing that trips people up about trunk based development. If everyone merges to main multiple times a day, what happens to features that aren’t finished?
Feature flags handle that. Incomplete code gets merged but stays hidden behind a toggle. Users never see it. The code exists in production, but it’s off.
Recent industry findings show an 89% reduction in deployment-related incidents after implementing feature switches, according to Nudge’s 2025 research. That’s not a small number.
How Feature Flags Fit the Workflow
Development: A developer writes the first slice of a new feature, wraps it behind a flag, and merges to main.
Testing: QA teams toggle the flag on in staging or for specific user segments. They validate without affecting anyone else.
Release: When the feature is ready, a product manager or developer flips the flag for all users. No deployment required.
Rollback: Something breaks? Turn the flag off. Instantly. No code revert, no emergency deploy.
LaunchDarkly, Unleash, and Flagsmith are the most commonly used tools in this space. Even a simple config-based boolean in your application works for smaller teams.
The Debt Side of Feature Flags
Flags that live too long become a problem. I’ve seen codebases where feature flags from two years ago are still scattered around, and nobody knows if they’re safe to remove.
This is called flag debt. It’s real, and it gets worse quickly.
Best practice: assign a cleanup schedule. Monthly or quarterly, go through your active flags and retire anything that’s been fully rolled out. LaunchDarkly and similar platforms include analytics that help identify stale flags.
Also, make sure your CI pipeline tests against multiple flag states. If you’re only testing with all flags on, you’re missing half the picture.
Trunk Based Development and Continuous Integration
Trunk based development without CI breaks fast. There’s no way around it.
When every developer on a team pushes code to the same branch multiple times a day, you need automated tests catching problems before they compound. That’s what a deployment pipeline does. Every commit triggers a build. Tests run. If the build fails, the team stops and fixes it before moving on.
The global continuous integration tools market was valued at $1.35 billion in 2024 and is projected to reach $6.11 billion by 2033, growing at 18.22% CAGR, according to Straits Research. That growth reflects how central CI has become to modern software development.
What Happens When a Build Breaks
A broken build on main blocks everyone. Not just the person who pushed the bad commit. The entire team.
This sounds painful, and it is. But that’s the point. The cost of a broken build is felt immediately, which creates strong incentive to write small, tested commits. Took me a while to appreciate this when I first worked in a trunk based setup. You stop committing large, untested chunks real quick when your teammates are waiting on a fix.
DORA’s research consistently shows that the combination of trunk based development and a maintained suite of fast automated tests is what makes continuous integration work. One without the other is incomplete.
CI Tools That Support This Model
Jenkins still holds 47.13% market share in CI/CD tools, though cloud-hosted alternatives are gaining ground fast.
GitHub Actions has become the default for teams already on GitHub. CircleCI and GitLab CI are strong options for larger organizations. The actual tool matters less than the practice: every commit to main runs the full test suite. No exceptions.
Approximately 85% of leading technology companies had implemented CI/CD pipelines for their main products as of 2025, according to Command Linux research. If you’re running trunk based development without one, you’re driving without brakes.
Scaling Trunk Based Development for Large Teams
A five-person startup can do trunk based development without thinking too hard about it. Thirty developers? You need structure. Thousands? You need serious tooling investment.
Google operates trunk based development with 35,000 developers and QA automators working in a single monorepo trunk. That’s not an accident. It’s the result of years of investment in custom build systems, code review processes, and automated testing infrastructure.
Code Ownership at Scale
When hundreds of people commit to the same branch, you need clear rules about who can approve changes to which directories.
Google uses programmatic ownership checks. A random Cloud engineer can’t approve changes to YouTube’s algorithm code. CODEOWNERS files on GitHub and GitLab serve a similar purpose for smaller organizations.
The 2024 DORA report found that teams with well-defined responsibilities and empowered decision-making autonomy show stronger performance across all delivery metrics. Code ownership models support exactly that.
Monorepos and Trunk Based Development
Monorepos and trunk based development show up together for a reason. When all your services, libraries, and frameworks live in a single repository, atomic cross-service changes become possible. You update a shared library and every consumer gets the change on their next sync.
Google, Meta, Microsoft, Uber, and Airbnb all use monorepos at significant scale. Google’s repo alone holds over 86 TB of storage with more than 35 million commits logged since the early 2000s.
But the tooling overhead is real. Standard Git doesn’t handle monorepos at this size gracefully. You need build systems like Bazel (Google), Buck (Meta), or Pants (Twitter) that process dependency graphs and only rebuild what’s actually affected by a commit.
Release Trains and Branch-for-Release
Even in trunk based development, you’ll sometimes cut a release branch. This isn’t the same as a long-lived feature branch.
A release branch is a snapshot of the trunk at a specific point. Bug fixes get cherry-picked into it. New features don’t. It exists purely to stabilize a release while development continues on main.
Google uses this pattern. Release branches host deployments, usually managed through A/B testing and feature flags. Their purpose is risk management for the deploy, not blocking the mainline. The 2024 Puppet State of DevOps Report found that 81% of top-performing IT teams use continuous delivery practices, and release branching is a standard part of that workflow for teams that can’t deploy directly from trunk on every commit.
Common Problems with Trunk Based Development
Trunk based development isn’t painless. The benefits are real, but so are the tradeoffs. Ignoring them leads to teams that adopt the model and then quietly abandon it three months later.
Flaky Tests Become Everyone’s Problem
Trunk.io analyzed 20.2 million CI jobs across their beta customers and confirmed what most teams already suspect: flaky tests are the biggest challenge to CI stability.
In a trunk based workflow, a flaky test doesn’t just annoy one developer on their branch. It blocks the entire team’s main branch. Google reported that 14% of their large tests were flaky in a given week. At their scale (over 4.2 million tests), that’s a huge number of false failures.
Uber ran into this hard. Their iOS mainline was green only 52% of the time when measured over a week, which forced them to build an internal merge queue system called SubmitQueue just to keep trunk stable.
Code Review Bottlenecks
DORA’s research identifies heavyweight code review as one of the most common obstacles to trunk based development adoption. When reviews require multiple approvals and take hours or days, developers batch up changes instead of committing small.
That defeats the entire purpose. Large batches lead to larger merge requests, which reviewers procrastinate on, which leads to even bigger batches. It’s a downward spiral that DORA has documented across multiple report years.
Junior Developer Challenges
The safety net is smaller. In feature branching, a junior developer can experiment on an isolated branch without worrying about breaking main. In trunk based development, every commit hits the shared branch.
AB Tasty’s analysis notes that trunk based development works best with experienced, senior developers who have the autonomy and discipline to self-manage their work. Teams heavy on junior engineers need stronger guardrails: pair programming, pre-merge CI checks, and clear commit guidelines.
Feature Flag Maintenance
We covered this in the feature flags section, but it’s worth repeating here as a standalone problem. Flags accumulate. Codebases end up with hundreds of toggles, and nobody tracks which ones are still active.
The 2024 Global DevOps Skills Report by DevOps Institute found that more than 57% of organizations struggle to fill qualified CI/CD professional roles. When those positions go unfilled, flag cleanup is usually the first thing that gets deprioritized.
| Problem | Root Cause | Mitigation |
|---|---|---|
| Flaky tests | Non-deterministic test behavior | Quarantine + monitoring tools |
| Code review delays | Multi-approval processes | Single-reviewer policy, smaller diffs |
| Junior dev risk | Less isolation from main | Pair programming, pre-merge CI |
| Flag debt | Forgotten feature toggles | Scheduled cleanup sprints |
When to Use Trunk Based Development
Not every team needs this. And not every project benefits from it. The decision depends more on how often you deploy than how many people are on the team.
Strong Fit
SaaS products and web applications: If you deploy to production multiple times a week (or daily), trunk based development removes friction that long-lived branches create.
Teams practicing continuous delivery: The 2024 Puppet State of DevOps Report found that 81% of top-performing IT teams use CD practices as part of their strategy, deploying up to 46 times more often with lower failure rates. Trunk based development is how they get there.
Teams larger than five developers: Merge conflicts from GitFlow compound as team size grows. Trunk based development pushes integration pain earlier, when the diffs are still small.
Weak Fit
Open source projects with external contributors need stricter gatekeeping on changes. A trunk based model where anyone merges to main quickly doesn’t work when you can’t vet every contributor.
Regulated industries with strict audit trails per feature sometimes need the documentation isolation that feature branches provide. AWS guidance specifically notes that trunk based development offers less control over releases for projects with strict release schedules.
Teams without CI infrastructure should not attempt this. The DevOps market has grown from 33% company adoption in 2017 to roughly 80% in 2024 (Brokee research). But if your team is in the remaining 20% without automated testing and build pipelines, you have more foundational work to do first.
The Hybrid Option
Pinterest is in the middle of a three-year migration involving more than 1,300 repositories being consolidated into four monorepos, paired with trunk based development.
That kind of gradual shift is common. Some teams use trunk based development for core services and a different Git workflow for client libraries or open-source modules. Your mileage may vary, and that’s fine.
| Scenario | Recommendation |
|---|---|
| SaaS with daily deploys | Strong fit |
| Mobile apps with app store releases | Moderate fit (use release branches) |
| Open source with many contributors | Weak fit |
| Packaged software, versioned releases | Consider GitFlow instead |
| No CI pipeline in place | Build CI first, then adopt |
How to Adopt Trunk Based Development
Switching from long-lived feature branches to trunk based development is not a flip-the-switch moment. It’s a gradual compression of branch lifespans, supported by tooling and team buy-in.
Shorten Branch Lifespans First
Don’t jump straight to committing directly to main. That’s too big of a leap for most teams.
Start by measuring how long your current branches live. If it’s weeks, cut it to days. If it’s days, cut it to hours. The CD Foundation’s 2024 State of CI/CD Report, based on over 150,000 respondents, found a direct correlation between the number of integrated DevOps practices a team uses and their likelihood of being a top performer.
Track two metrics from day one: branch lifespan and merge frequency. If branches are getting shorter and merges are happening more often, you’re moving in the right direction.
Set Up CI Before Changing Strategy
The safety net has to exist before you start doing the trapeze work.
Straits Research valued the global continuous integration tools market at $1.35 billion in 2024, projected to hit $6.11 billion by 2033. The tooling is mature and accessible. Jenkins, GitHub Actions, CircleCI, or GitLab CI all work. Pick one and get every commit running through automated tests.
A Deloitte study found companies with skilled DevOps engineers reported a 30% improvement in deployment frequency. The tooling matters, but having people who know how to configure and maintain it matters more.
Introduce Feature Flags Gradually
Pick one project or one service. Wrap its next feature behind a flag. Merge to main with the flag off. Test it in staging with the flag on. Release by flipping the toggle.
That single cycle teaches your team the pattern without forcing a wholesale process change. Tools like LaunchDarkly, Unleash, and Flagsmith all offer free tiers or open-source options to get started.
Travis CI’s guidance recommends listing your requirements, getting team buy-in, and then training everyone before making the switch. The team’s consensus matters. You can’t force trunk based development on a group that doesn’t understand why the old way is creating problems.
Measure What Matters
Four metrics to track (aligned with the DORA framework):
- Deployment frequency
- Lead time for changes
- Change failure rate
- Failed deployment recovery time
The 2024 DORA report found that only 19% of teams reached elite performance across these metrics. But even moving from “low” to “medium” produces meaningful gains in delivery speed and stability.
For deeper reading, trunkbaseddevelopment.com is the most comprehensive community resource. It covers everything from source control patterns to code refactoring strategies specific to this workflow. The books Continuous Delivery by Jez Humble and Dave Farley, and the DevOps Handbook, both cover the practice in detail.
FAQ on What Is Trunk Based Development
What is trunk based development in simple terms?
Trunk based development is a branching model where all developers commit small, frequent changes to a single shared branch called the trunk. There are no long-lived feature branches. Integration happens continuously, not at the end of a sprint.
How does trunk based development differ from GitFlow?
GitFlow uses multiple long-lived branches (develop, release, hotfix, feature). Trunk based development uses one. Merge frequency is daily or more in trunk based workflows, while GitFlow batches merges at the end of feature cycles.
Is trunk based development the same as continuous integration?
Not exactly, but they’re tightly connected. Trunk based development is a required practice for continuous integration according to DORA research. CI adds automated builds and tests on top of the branching model.
Do you need feature flags for trunk based development?
In most cases, yes. Feature flags let developers merge incomplete work to main without exposing it to users. Tools like LaunchDarkly, Unleash, and Flagsmith handle this. Without flags, unfinished features would ship to production.
Can junior developers work in a trunk based setup?
They can, but it requires stronger guardrails. Pair programming, pre-merge CI checks, and clear commit guidelines help. The model gives less isolation than feature branching, so mentorship and test-driven development practices matter more.
What tools support trunk based development?
Git is the standard version control system. GitHub, GitLab, and Bitbucket all support the workflow through pull requests and CI integrations. Jenkins, CircleCI, and GitHub Actions handle the automated build pipeline side.
Does trunk based development work for large teams?
Yes. Google runs it with over 35,000 developers in a single monorepo. It requires investment in build systems like Bazel, code ownership models (CODEOWNERS files), and fast automated testing infrastructure to work at that scale.
What are the biggest risks of trunk based development?
Flaky tests blocking the whole team, code review bottlenecks slowing merge frequency, and feature flag debt accumulating over time. Without strong CI and team discipline, the shared trunk breaks often and productivity drops.
How do you start adopting trunk based development?
Shorten your existing branch lifespans first. Go from weeks to days, then days to hours. Set up a CI pipeline before changing your branching strategy. Introduce feature flags on one project as a trial run.
When should you avoid trunk based development?
Open source projects with external contributors, teams without automated testing, and projects requiring strict per-feature audit trails are poor fits. If you ship packaged software with formal release cycles, GitFlow may serve you better.
Conclusion
Understanding what is trunk based development comes down to one idea: merge small, merge often, and keep the main branch deployable at all times. The model works because it forces teams to deal with integration problems early, when fixes are cheap and diffs are tiny.
It’s not for everyone. Teams without automated testing or a proper testing infrastructure will struggle. Open source projects and strict release-schedule environments may need a different branching strategy entirely.
But for teams shipping SaaS products, practicing incremental development, and investing in CI/CD tooling, trunk based development removes friction that slows delivery down.
Start by shortening your branch lifespans. Build your safety net with CI. Add feature flags where needed. The shift doesn’t happen overnight, but every step toward shorter feedback loops makes your release cadence faster and your codebase healthier.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.
- How to Set Up Subscriptions on Google Play (Developer Guide) - July 12, 2026
- Why Work With a CMS Development Company for a Secure and Scalable Website? - July 12, 2026
- ADB Commands Cheat Sheet - July 11, 2026
