Updated October 2026

Trunk-based development is a branching strategy where every developer merges small changes into one shared branch, the trunk (usually main), at least once a day. Branches, if a team uses them, live for a day or two at most. Unfinished features stay hidden behind feature flags, so the trunk is always ready to release.

• Main branch: One shared trunk, always releasable
• Branch lifespan: Hours to a day or two
• Unfinished work: Hidden behind feature flags
• Best for: Teams practicing continuous integration and delivery

This guide covers how trunk-based development works, its pros and cons, best practices, and how it compares to Gitflow. To compare every major strategy side by side, see our guide to Git branching strategies.

GitKraken Desktop shows every branch in one commit graph, so short-lived branches stay visible until they merge. Download GitKraken Desktop free.

• What is Trunk Based Development
• Benefits of Trunk Based Development
• The Cons of Trunk Based Development
• Trunk Based Development Best Practices
• Popular Git Branching Strategies
• Gitflow vs Trunk Based Development 

What is Trunk Based Development?

In trunk-based development, developers integrate their work into the trunk continuously instead of building features on long-lived branches. Small teams often commit straight to main. Larger teams use short-lived feature branches that go through a quick pull request review and merge within a day or two.

Two techniques make this work:

• Feature flags let you merge code for a feature before it’s finished, with the feature switched off in production.
• Branch by abstraction lets you replace a large piece of the system gradually, behind an abstraction layer, without a long-running branch.

When it’s time to ship, teams release straight from the trunk. Teams that need to support a version can cut a release branch from the trunk and cherry-pick fixes into it.

Benefits of Trunk Based Development

Fewer merge conflicts. Small, daily merges mean branches never drift far from the trunk, so conflicts stay small and easy to resolve.

Built for CI/CD. The trunk is always releasable, which is what continuous integration and continuous delivery require. DORA research lists trunk-based development as one of the capabilities linked to better software delivery performance.

Faster feedback. Everyone sees changes as soon as they land, so problems surface in hours instead of at the end of a sprint.

Simpler history. With fewer long-lived branches, the commit history is easier to read and debug.

Engineering leaders can track whether the switch is working with GitKraken Insights, which reports DORA metrics like deployment frequency and lead time for changes.

Challenges of trunk-based development

Trunk-based development has fewer branches than other strategies, but it asks more of your team and your tooling.

• It depends on strong automated testing. Every merge lands on a releasable branch, so a weak test suite lets bugs into production.
• It requires discipline. Developers have to break work into small pieces and merge daily, even when a feature isn’t finished.
• Feature flags add their own overhead. Flags need to be managed and removed once a feature ships, or they pile up as technical debt.
• It’s a harder adjustment for newer developers. Committing to a shared, releasable branch can feel risky without fast reviews and clear guardrails.

As Ben Morris puts it in Why Trunk Based Development Isn’t for Everybody, trunk-based development reduces merge conflicts but doesn’t remove the complexity of building features in parallel. It moves that complexity into code design and configuration.

Trunk Based Development Best Practices

Merge at least once a day. If a branch lives longer than two days, break the work into smaller pieces.

Keep pull requests small. Small PRs get reviewed in minutes instead of days.

Automate your tests and builds. Every merge to the trunk should trigger a build and the full test suite.

Use feature flags for unfinished work. Merge early and turn the feature on when it’s ready.

Fix a broken trunk immediately. A failing build on the trunk blocks everyone, so fixing it comes before any new work.

Delete branches after merging. Stale branches make it harder to see what’s actually in progress.

Popular Git Branching Strategies

When compared to Trunk Based Development, the following Git branching strategies are workflows that make having multiple parallel development paths for an application simpler and less error-prone. More straightforward branching strategies in Git can help inform individual developers how to integrate their changes into the main production version of the code.

Well-selected Git branching strategies offer development teams many potential benefits, including:

• Streamlining parallel development
• Promoting efficient team collaboration
• Providing clear-cut development workflows for integrating changes into production code
• Minimizing Git merge conflicts
• Limiting the introduction of bugs into the production code
• Providing a streamlined roadmap for new releases

The most popular Git branching strategies include: Gitflow, GitHub flow, and GitLab flow.

Gitflow

Gitflow has historically been one of the most popular branching strategies for teams using Git. The strategy uses five different branch types in total: two primary branches – the main and develop branches – along with three special purpose branches such as feature, release, and hotfix. The main branch in Gitflow uses tags to identify specific production versions (0.1, 0.2, 1.0 as shown in the diagram below). Develop branches are cloned from a tagged main branch version. 

Using Gitflow, many developers can work in parallel, collaborating within the feature branches before the release of new candidates. And because Gitflow uses a separate sandboxed staging area for releases, it can help development teams ensure that only verified functionality makes it to production. Separate release branches also allow teams to easily integrate security-by-design principles into the development process.

Special purpose branches are created from the develop branch, and multiple special purpose branches can exist simultaneously. While the main and develop branches are perpetual, feature branches typically only exist as long as necessary to complete a particular task, which can be days, weeks, or even months. 

Teams work directly together in the feature branches. As they complete the development of a feature, they merge it back into the develop branch. There is no set schedule for merging new features – merges occur as needed.

In addition to feature branches, developers can work with hotfix branches to quickly resolve issues in the production code. Unlike feature branches, hotfix branches extend from the main branch. However, developers must remember to merge completed hotfixes into both the main and develop branches.

Development teams may clone a release branch from the develop branch. The release branch serves as a testing and QA sandbox for new release candidates. As with hotfix branches, finalized modifications in the release branch must be merged into both the main and develop branches. 

Vincent Dreissen, the creator of Gitflow, created a useful summary overview graphic of the various Gitflow branches and how they relate to each other: 

Gitflow vs Trunk Based Development

With its highly organized, well-defined, and well-segregated structure, Gitflow makes it easy to know what’s going on in a project at any given time. However, the addition of numerous branches increases the risk of merging conflicts. And the larger the team, the larger the risk of introducing problems into the main codebase. 

Because the Gitflow strategy requires a developer to perform many different commits before code goes into production, project history can become difficult to analyze. Tracking errors back through the complex web of branches and commits can be time-consuming and frustrating. Indeed, even though Gitflow aims to speed development, if individual developers lack an understanding of how to properly implement the strategy into their workflow, success will be unlikely. 

If you team does need more visibility into their project history, a robust but easy-to-use Git GUI like GitKraken Client can make a huge difference for developers of every skill level. Setting up Gitflow in GitKraken Client is extremely easy and intuitive, requiring just 3 steps.

The complex nature of Gitflow and lack of defined times for commits to the main branch also make it unsuitable when teams want to implement continuous integration/continuous delivery (CI/CD) workflows. By its very nature, continuous integration is predicated on regular, periodic merges of code changes to the master branch. On the other hand, if your project allows for longer periods between deployments, Gitflow can be an excellent choice.

Similarly, continuous delivery requires the ability to go to production immediately. In Gitflow, however, developers must create a release branch, merge it into the main and develop branches, and tag the new production version in the main branch before changes get to production. Gitflow really encourages more of a discontinuous delivery process than continuous.

GitHub Flow

GitHub flow is a simplified version of Gitflow that eliminates the develop and release branches. Instead, feature branches come directly from the main branch. 

With this strategy, developers commit changes to the feature branch and test them there as well. Only after making a go decision do developers merge the feature branch to the main branch.

Because GitHub flow lacks the intermediate branches of Gitflow, the history is easier to follow. And unlike Gitflow, GitHub flow integrates easily into CI/CD pipelines.

One downside of GitHub flow is that failure to adequately test feature changes before merging them into the main branch can lead to buggy and unstable production versions.

Because it’s lightweight and faster than other Git branching strategies, GitHub flow works well for small teams applying agile development principles. As teams increase in size, however, GitHub flow loses its beneficial qualities.

GitLab Flow

Another simplified version of Gitflow, GitLab flow uses a pre-production branch for testing changes before merging them back to the main branch and going to production. GitLab flow focuses on issue tracking, building useful histories as new features are merged into the main branch. And as with GitHub flow, GitLab flow is more viable when working with CI/CD.

Is Trunk Based Development Right for You?

Trunk based development and other branching strategies each have areas where they excel and where they fall behind. Fortunately, if your needs or circumstances change during a project, it is possible to switch from one strategy to another.

Keeping track of changes and versions throughout the software development lifecycle is a crucial but less than simple task.  Ultimately, trunk based development and popular Git branching strategies should provide developers with the tools they need to ensure robust, stable production versions while allowing them to deploy changes as frequently as desired. 

As with most tools, there is no “one size fits all solution.” Consider the composition of your development team and the needs of each specific project to decide which path is right for you. And, if you don’t succeed at first, shift to another approach. It’s really as simple as that.

FAQ

What is the trunk in trunk-based development?
The trunk is the single shared branch everyone merges into, usually main. It’s always kept in a releasable state.

Does trunk-based development use feature branches?
It can. Small teams often commit directly to the trunk. Larger teams use short-lived feature branches that merge within a day or two.

Is trunk-based development better than Gitflow?
It depends on how you release. Trunk-based development fits teams practicing continuous delivery. Gitflow fits products with scheduled releases or several supported versions.

What do you need before switching to trunk-based development?
You need automated tests that run on every merge, a fast code review process, and a way to manage feature flags.