# What Is Trunk-Based Development? The Git Strategy Explained

URL: https://formula.dog/journal/what-is-trunk-based-development
Type: blog
Locale: en
Published: 2026-09-12
Updated: 2026-09-13

---

> All developers push to main daily. Trunk-based development trades branch complexity for shipping speed -- here is the full picture in plain language.

What is trunk based development? Every developer on the team commits code to a single shared branch called the trunk -- usually named main -- at least once a day. No long-lived feature branches. No hotfix-v2-backup-final sitting around for three weeks. Short branches live for hours, merge fast, and get deleted. The codebase stays continuously releasable. [Google runs 35,000 developers this way](https://trunkbaseddevelopment.com/). Here is how it works, when it makes sense, and when it does not.

## The "report_v2_FINAL_use_this_one.xlsx" problem -- but for code

If you have ever opened a shared folder and found `report_v1.xlsx`, `report_v2_FINAL.xlsx`, and `report_USE_THIS_ONE_greg_edits.xlsx` sitting side by side, you already understand the pain trunk-based development is trying to solve.

That exact situation happens in codebases when teams use long-lived feature branches. Someone starts a feature in week one. The rest of the team keeps shipping. By week three, that branch is dozens of commits behind main. Merging it becomes a weekend project nobody wants to own. Conflicts pile up. The developer who wrote the code has forgotten why half of it exists. This is "merge hell."

Gitflow -- the most widely taught alternative -- tries to solve this with formal structure: separate branches for features, releases, and hotfixes, each with a defined lifespan. The structure looks clean on paper. In practice, branches accumulate like spreadsheet versions in a shared drive, and integration day turns into integration week.

Trunk-based development takes the opposite stance: stop accumulating integration debt. Commit to main. Today.

## Everyone commits to main. Every day. That is the whole model.

The core rule is straightforward: all developers push changes to the shared trunk at least once every 24 hours. No exceptions for "I am not done yet" -- you commit what you have, and you make sure what you have does not break the build.

This sounds alarming until you understand the mechanisms that make it safe:

- 
**Short-lived branches**: You can still use branches, but they live for hours, not weeks. A branch that lasts more than two days is a warning sign worth investigating.

- 
**Automated testing on every commit**: Your CI pipeline runs the test suite immediately. If something breaks, you know in minutes, not at the end of a sprint.

- 
**Feature flags**: Half-built features stay hidden behind a toggle until they are ready to ship. Users never see incomplete work, even though it is already in production code.

The result is a codebase that is always releasable -- not "releasable after we merge the feature branch and run QA for a week," but releasable right now if needed. That is the fundamental promise.

![Multiple code commits converging into one main branch in trunk-based development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/f48347-inline1.webp)

## Short-lived branches: measure them in hours, not weeks

In trunk-based development, you are not banned from branches. You are banned from long branches.

A branch you open at 9 AM, work on through the morning, get a code review on after lunch, and merge to main before 5 PM is exactly the right kind. It gives your teammates a chance to review the work before it lands on trunk. It is small enough to understand in one read. Conflicts, if any, resolve in minutes.

A branch that lives three weeks while one developer builds an entire authentication system in isolation is the problem. When it finally comes time to merge, the team spends more time resolving conflicts than it spent building the feature.

The practical threshold most trunk-based teams use: if a branch has not merged within two days, something needs to change. Either the feature is too large and needs breaking into smaller pieces, or it needs a feature flag so partial work can land safely.

Breaking work into smaller pieces is the core discipline trunk-based development actually develops. Instead of "build the whole dashboard," you ship "add the data layer," then "add the first chart," then "wire up the filters." Each piece merges to trunk, gets tested, and ships independently. The full feature emerges incrementally over several commits.

This sounds slower. In practice it is faster, because you find problems while the context is still fresh and the surface area is still small.

## Feature flags: how you ship incomplete work without breaking anything

Feature flags (also called feature toggles) are the mechanism that makes trunk-based development practical when a feature cannot be finished in a single short-lived branch.

The idea is simple: wrap new functionality in a conditional that only activates when a specific flag is turned on.

`if (featureFlags.newReportingDashboard) {
  renderNewDashboard();
} else {
  renderOldDashboard();
}`The new code is deployed to production. It just does not run for users until you flip the toggle. This means:

- 
Developers can commit work-in-progress to trunk without affecting anyone

- 
QA can test the feature in production by enabling the flag for a specific user or environment

- 
A launch becomes a configuration change, not a deployment event

- 
If something breaks, you turn the flag off without a rollback or hotfix branch

Feature flag infrastructure scales from a simple environment variable checked at startup to dedicated feature flag platforms. For a team just starting out, a config file or per-environment variable is enough. The point is the capability, not the tooling complexity.

![Feature flag toggle switches controlling code deployment in trunk-based development](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/d557e7-inline2.webp)

## When trunk-based development is not the right call

It is worth saying directly: trunk-based development is not universally better. It fits specific contexts.

Skip it if:

**Your CI/CD pipeline is not ready.** Trunk-based development without automated tests on every commit is not a branching strategy -- it is a broken codebase accumulating fast. The testing infrastructure has to be in place before the branching model can work.

**The team cannot commit frequently by nature.** Distributed teams where contributors work asynchronously across time zones, or open-source projects where contributors submit infrequent batches, will struggle with the daily commit cadence.

**You are in a regulated environment with mandatory release windows.** Some industries require external sign-off, long QA cycles, and formal audit trails by release branch. Gitflow's structured release branches map better to that kind of workflow.

**Team discipline is not there yet.** Trunk-based development requires that every commit to main either passes all tests or gets fixed immediately. If your team tolerates broken builds, the shared trunk becomes everyone's shared problem.

Gitflow is a reasonable choice for teams with quarterly release schedules, multiple concurrent features developed by separate squads, or compliance requirements that demand branch-level isolation. The question is honest fit, not which approach wins on principle.

## How to move from Gitflow to trunk-based development without a crisis

If your team is on Gitflow and wants to try trunk-based development, the migration does not have to be a hard cutover.

Start by stopping the creation of new long-lived branches. Features started after the decision get short-lived branches. Features already in progress on long branches finish under the old model. The two approaches coexist temporarily.

Before committing unfinished work to trunk, you need feature flags in place. Setting up even a basic feature flag system is the prerequisite for everything else. Without it, trunk-based development means shipping incomplete UI to production users.

Then enforce CI on the main branch: automated tests run on every push, failing tests block the merge, and no one merges without a passing build. This is the non-negotiable part.

Finally, define the two-day rule explicitly: any branch older than two days gets a conversation about what to do with it. Break the feature smaller, add a flag, or ship what is already done. Make this visible in your pull request process.

The uncomfortable adjustment most teams face: accepting that "partially complete" is a valid thing to commit, as long as it is hidden behind a flag and does not break existing tests.

## What the DORA report data says about shipping speed

The DevOps Research and Assessment (DORA) reports are the closest thing software development has to large-scale empirical research on team practices. The 2021 DORA report found that elite-performing teams are 2.3 times more likely to use trunk-based development compared to lower-performing teams.

Elite performers in the DORA framework deploy multiple times per day, with lead times from commit to production measured in hours rather than weeks. Trunk-based development correlates consistently with those outcomes.

The important caveat: correlation is not causation. High-performing teams adopt trunk-based development because they have already invested in the underlying discipline -- automated testing, solid CI/CD infrastructure, engineers who write small, focused changes. Those foundations come first. Trunk-based development is the branching model that fits that context, not the thing that creates it.

Biscuit figures this one out fast: a good retriever does not try to carry three balls at once. One commit, one review, one merge. Good boy.

![Continuous deployment pipeline visualization showing code flowing from commits to production](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/6305c9-inline3.webp)

## Is trunk-based development worth switching to?

If your team spends meaningful time each sprint on merge conflicts, delays releases because "the feature branch is not ready," or has branches open so long no one remembers what they were for -- trunk-based development is worth a serious evaluation.

The daily commit cadence is demanding. The feature flag infrastructure takes setup. The cultural shift takes a few weeks. But the outcome -- a codebase that is always releasable, merge conflicts measured in lines not files, and releases that are routine rather than crises -- is a meaningful improvement in how the team works.

Start small: one team, one sprint, CI running on every push, feature flags in place. See what changes in four weeks.

## FAQ

### What is the difference between trunk-based development and Gitflow?

Gitflow uses multiple long-lived branches (develop, release, hotfix, feature) with formal roles for each. Trunk-based development uses a single main branch and short-lived branches that merge back within hours or days. Gitflow fits scheduled release cycles; trunk-based fits continuous delivery environments where the team ships frequently.

### Do you need feature flags for trunk-based development?

Not for very small features that can be completed and merged in a single day. But for anything that takes more than a day to build, feature flags are how you commit incomplete work to trunk without breaking what users see. Most trunk-based teams treat them as standard practice rather than an optional extra.

### Is trunk-based development good for small teams?

Yes. Small teams often find it easier to adopt because coordination overhead is low and the team can respond quickly when something breaks on trunk. The daily commit discipline and short branch duration are both easier to maintain when everyone is working closely together and can communicate immediately.

### How do code reviews work in trunk-based development?

Code review happens on short-lived branches before they merge to trunk. The review is faster because the change is smaller -- a few hundred lines instead of a few thousand. Some teams also use pair programming to review in real time. The key requirement is that review happens before merge, not after.

### What companies use trunk-based development?

Google is the most documented case: 35,000 developers and QA automators working in a single monorepo trunk. Facebook, Netflix, and parts of Microsoft also use trunk-based development or close variants. It is common at companies where continuous deployment is the norm and fast iteration is a competitive advantage.

### Can trunk-based development work without a CI/CD pipeline?

Not safely. Without automated tests running on every commit, daily pushes to a shared trunk quickly produce a broken codebase. CI is the enforcement mechanism that makes the model viable -- it tells you within minutes whether a commit broke something. Getting CI in place is the prerequisite, not an optional step.