Trunk-based development

Trunk-based development is a branching model where developers integrate work into one shared branch, usually main, at least once a day. The shared branch should stay releasable. Work is split into small changes, and incomplete features are hidden behind feature flags or merged through safe intermediate steps.

The point is to avoid long-lived branches. Long-lived branches drift from main, hide conflicts, delay testing, and make releases larger than they need to be.

The basic rule

main is the source of truth. A developer can still create a branch, but it should be short-lived. The branch exists to prepare a small change, not to hold an entire feature for weeks.

A normal flow looks like this:

1. Create a small change.
2. Open a pull request.
3. Run CI.
4. Review it.
5. Merge to main.
6. Deploy from main.

If a change is too large to merge safely, split it.

Keeping main releasable

Trunk-based development depends on CI. At minimum, every pull request should run tests, linting, type checks, build checks, and any security checks that matter for the project.

A failing check should block the merge. If main is not protected, people stop trusting it. Once people stop trusting it, deployments become manual and slow again.

Feature flags

Feature flags separate deployment from release. Deployment means the code is in production. Release means users can access the feature. Those should not always happen at the same time.

A feature flag lets you merge code early while keeping it disabled. This makes larger work easier to split: merge the database change, merge the backend path behind a flag, merge the UI hidden from users, and enable the feature later.

This keeps changes small without forcing unfinished work onto users.

Release branches

Some teams still need release branches. That is fine for short stabilization windows, versioned products, or regulated release processes.

The important part is that release branches should not become a place where normal development continues for a long time. Most work should still integrate into trunk quickly.

Why smaller changes help

Small changes are easier to review, test, deploy, and revert. When a deployment contains one small change, the cause of a problem is usually clear. When a deployment contains weeks of unrelated work, debugging becomes slower and rollback becomes harder.

Trunk-based development reduces release risk by reducing the size of each release.

Adopting it

Start with one repository. Make pull requests smaller. Make CI required. Deploy from main. Add feature flags for unfinished work. Fix slow or flaky checks before expanding the process.

The goal is not to deploy recklessly. The goal is to keep integration continuous so releases stay small.