What Is Trunk-Based Development?

TLDR; Trunk-based development is a branching strategy in which developers integrate small changes into one shared branch called main or trunk. Very small teams may commit directly to main. Other teams use short-lived branches and pull requests that are merged within hours rather than weeks. The goal is the same: keep changes small, receive feedback early, and keep the codebase ready to release.

What Is Trunk-Based Development?

Trunk-based development is a way for a team to work together in a Git repository. Everyone integrates their changes into one central branch called the trunk. In most Git repositories, this branch is named main.

You can imagine the repository as a tree. The trunk is the strong, shared line of development. A feature branch grows away from it. The longer that branch grows on its own, the more difficult it becomes to bring it back. Trunk-based development keeps these branches short.

This does not mean that every developer must commit directly to main. A team can use pull requests, code reviews, and short-lived feature branches. What matters is that developers work in small batches and integrate them at least once a day.

According to DORA, trunk-based development is a required practice for continuous integration. It reduces the number of separate development lines and the complexity of merging them.

How Does Trunk-Based Development Work?

A developer starts with the newest version of main, creates a small change, runs the tests, and integrates the change as soon as it is safe. If the team uses pull requests, the branch exists only for the review and automated checks. It is deleted after the merge.

Here is a small example using the project from our Ultimate Git Cheat Sheet:

# start with the newest main branch
$ git switch main
$ git pull --ff-only

# create a branch for one focused change
$ git switch --create feature/add-branch-tip

# edit, review and commit the change
$ code branches.md
$ git add branches.md
$ git commit -m "Add branch cleanup tip"

# run the tests before sharing the change
$ npm test

# publish the branch for review
$ git push --set-upstream origin feature/add-branch-tip

After the checks and review pass, merge the pull request and delete the branch. Then start the next change from the newest main.

The pull request should contain one small, understandable step. Do not keep adding unrelated work while you wait for the original change to be reviewed.

Do You Commit Directly To Main?

Very small teams can commit directly to main when they have fast automated tests and clear rules for fixing a broken build. This is the simplest form of trunk-based development.

Many teams need a review before a change reaches main. They use a short-lived branch, a pull request, and automated checks. This approach still counts as trunk-based development. A developer can work alone or with another developer (pair programming) on a small change. They merge the branch back into main within hours, or within a couple of days at most.

A pull request is not the problem. A long-lived branch is. If several developers work for weeks on the same feature branch, they have created another line of development. The team receives integration feedback only when the feature is almost finished.

Why Do Teams Use Trunk-Based Development?

Small and frequent integrations give a team several benefits:

• Smaller Merge Conflicts: A branch has less time to diverge from main, so fewer unrelated changes compete with each other.
• Faster Feedback: Automated tests and colleagues review the change while it is still small and fresh in the developer’s mind.
• Lower-Risk Changes: A small change is easier to understand, test, revert, and fix than a large collection of changes.
• Simpler Releases: The team has one current line of development instead of deciding which long-lived branches belong in a release.
• Continuous Integration: Developers integrate continuously instead of waiting until the end of a feature.

DORA’s research connects short branch lifetimes and frequent integration with higher software delivery and operational performance. Trunk-based development does not create these results alone. It needs reliable tests, quick feedback, and a team that treats a broken main as an urgent problem.

How Do You Handle Features That Take Longer Than One Day?

The feature can take several weeks, but its branch should not. Divide the work into smaller changes that are safe to integrate independently.

For user-facing behavior, place incomplete work behind a feature flag. The code can enter main while the feature remains disabled for users. Enable it later for your team, a small group of users, or everyone. Remove the flag after the rollout so temporary paths do not become permanent complexity.

For a large internal change, use branch by abstraction. Add a stable interface around the old implementation, build the replacement behind it in small steps, switch to the new implementation, and then remove the old one. The Trunk-Based Development guide explains this technique in more detail.

The important question is not: "How do we finish the complete feature today?" It is: "What is the smallest safe step that we can integrate today?"

What Does Trunk-Based Development Require?

Trunk-based development makes integration problems visible early. Your team needs a safety net to solve them quickly:

• Automated tests that provide useful feedback within minutes.
• A protected main branch with required checks when pull requests are used.
• Small changes that colleagues can review without waiting for hours.
• A clear rule to revert or fix a change when main breaks.
• Monitoring and deployment automation when the team releases frequently.

Without these practices, frequent integration can become frequent interruption. Start by improving the tests and reducing the size of each change.

What Are Common Trunk-Based Development Mistakes?

• Keeping "Short-Lived" Branches For Weeks: Rename the workflow if branches routinely stay open for an entire feature. It is no longer trunk-based development.
• Putting The Complete Feature In One Pull Request: Split refactoring, supporting code, and user-facing behavior into independently safe changes.
• Ignoring A Broken Main Branch: Stop new integrations, fix or revert the responsible change, and restore the shared branch quickly.
• Using Feature Flags Without Removing Them: Assign an owner and a removal condition to every temporary flag.
• Confusing Integration With Deployment: Merging into main does not require you to release every change immediately. Integration and deployment can happen at different times.

Is Trunk-Based Development Still Useful In AI-Driven Development?

Yes. AI can help produce a change, but that change still has to work with the rest of the system. When generated code arrives in a large batch, reviewers have more to understand before they can judge whether it is ready.

Trunk-based development gives that work a clear structure: ask for one small change, review it, run the tests, and integrate it before starting the next step. Frequent integration also reveals when separate changes, whether written by people or AI agents, do not work together.

DORA's guidance on small batches specifically recommends keeping AI-assisted changes small enough to review, test, and integrate safely. Our recommendation is to keep that discipline even when generating code becomes easier. Faster output is useful only when the team can understand and verify it. Keep required reviews, automated checks, and feature flags for unfinished behavior.

What Did You Learn?

Trunk-based development keeps one shared branch at the center of development. Developers integrate small changes at least daily, either directly or through short-lived branches and pull requests. Automated tests, quick reviews, feature flags, and a healthy main branch make the workflow safe.

If your branches remain open for weeks, start smaller. Choose one change that can be reviewed, tested, and integrated today. Then repeat the process tomorrow.

Continue with the Ultimate Git Cheat Sheet to learn the Git commands behind branches, commits, merges, conflicts, and remote collaboration.

You liked this article? Share it with your colleagues and friends.