Trunk-Based Development

Trunk-based development organizes collaboration around one shared branch called the trunk. In Git repositories, teams often name that branch main.

The important idea is not the branch name. It is the integration rhythm. You keep changes small, integrate them frequently, and treat the trunk as the current shared state of the product.

This practice addresses a basic coordination problem. Two changes can work in isolation and still fail when combined. Long-lived branches postpone that discovery. By the time they merge, their authors may need to reconcile weeks of changed assumptions.

Trunk-based development shortens that delay. It turns integration from a late project phase into a normal part of daily work.

The core model

Picture the repository as a stream:

small change → review and test → trunk → shared feedback
      ↑                                  ↓
      └──────── adjust the next change ──┘

Each integrated change gives the team a new shared baseline. The next change begins from that baseline instead of from a private version of the product.

DORA describes trunk-based development through observable behavior. Teams keep very few active branches. Those branches have short lifetimes. Teams also avoid code freezes or stabilization periods caused by difficult integration.

The dedicated Trunk Based Development reference describes two compatible working styles: