Trunk-Based Development

Q: What is the difference between trunk-based development and Git Flow?

Git Flow uses several long-lived branches, such as develop and release branches, and merges features in larger batches. Trunk-based development keeps one main branch and merges small changes into it continuously, which suits teams that release often.

Updated September 30, 20262 min read

In short

Trunk-based development is a branching strategy where developers merge small changes into one shared main branch at least daily, keeping it always releasable.

What is trunk-based development?

Trunk-based development is a version control workflow in which everyone integrates their work into a single shared branch, called the trunk and usually named main. Developers either commit directly to it or use very short-lived branches that are merged within a day or two. The goal is to keep the trunk working and ready to release at all times.

Because changes are small and frequent, each one is easy to review and rarely causes large merge conflicts. A fast automated CI pipeline runs tests on every change, so a break is spotted within minutes and fixed or reverted right away. Unfinished features are hidden behind feature flags, which are switches in the code that keep new functionality turned off for users until it is ready.

Think of a group writing one shared document where everyone adds a few sentences at a time and rereads the result, instead of each person writing a whole chapter alone and merging everything at the end. Trunk-based development is a key practice behind continuous integration and continuous delivery, and it is common in teams that deploy many times per day.

It is often contrasted with long-lived feature branches and with Git Flow, a model that uses separate develop, release, and hotfix branches. Those approaches can isolate work for weeks, which leads to painful merges and delayed feedback. Trunk-based development still uses pull requests and code review; the difference is that branches stay small and merge back quickly.

Key takeaways

Everyone integrates into a single shared branch, usually main.
Branches, if used, live for a day or two at most.
Automated tests on every change keep the trunk releasable.
Feature flags hide unfinished work from users.
It reduces merge conflicts compared with long-lived feature branches.

Example

A short-lived branch in a trunk-based workflowbash

# Start a short-lived branch from an up-to-date trunk
git switch main
git pull
git switch -c add-search-button

# Make a small change and commit it
git commit -am "Add search button behind a feature flag"

# Stay current with main, push, and open a small pull request
git pull --rebase origin main
git push -u origin add-search-button
# CI runs, a teammate reviews, and the branch merges the same day

Readers ask

What is the difference between trunk-based development and Git Flow?

Git Flow uses several long-lived branches, such as develop and release branches, and merges features in larger batches. Trunk-based development keeps one main branch and merges small changes into it continuously, which suits teams that release often.

Does trunk-based development mean no pull requests?

No. Many teams use short-lived branches with quick pull requests and code review, as long as each branch is merged within a day or two. Small or highly experienced teams sometimes commit directly to the trunk.

How do you ship unfinished features with trunk-based development?

You merge the code but keep it switched off with a feature flag until it is complete and tested. This lets work integrate early without exposing half-built features to users.