Trunk-based development: developers work in short-lived branches, integrate to main (trunk) frequently, ideally multiple times per day. Main is always deployable.
It's the dominant pattern in modern high-performing teams. The DORA research identifies trunk-based development as one of the practices that distinguishes elite from low-performing teams.
This page covers why it works and the practices that make it work.
Branches live for hours or days, not weeks. A long-lived branch is the failure mode.
Why: short branches merge cleanly; long branches diverge; merging long branches is painful.
Each developer integrates to main multiple times per day. CI runs on every push. Conflicts are caught immediately.
Why: integration problems are constant tiny problems instead of occasional huge problems.
Main always passes CI. Always shippable. If it breaks, fixing main is the team's top priority.
Why: continuous delivery requires deployable main. Otherwise "deploy" becomes "fix-and-deploy."
Code merges to main even when the feature isn't ready. The feature is hidden behind a flag.
Why: lets you merge frequently without users seeing half-done features. See FeatureToggleManagement.
Code is reviewed quickly; doesn't sit waiting for days.
Why: long review cycles defeat short branches. The branch ages while waiting.
GitFlow uses long-lived develop, feature, release, and hotfix branches. The complexity:
Trunk-based has:
For most modern teams with CI/CD, GitFlow is overkill. Trunk-based is simpler and shipping practices favor it.
For typical web/cloud software, none of these apply.
When a feature branch merges, squash to one commit. Main has clean history.
Some teams merge directly to main without PRs (with paired review or post-merge review). Others require PRs but keep them short-lived.
PRs add review structure but extend branch lifespan. The trade-off depends on team culture.
Required CI checks. Cannot merge to main if tests fail. Main quality is non-negotiable.
If main is broken, revert the bad commit. Fix forward later. Don't try to fix in place under pressure.
Some teams deploy main automatically. Others deploy main with manual approval. Either way, main is always ready.
Without good test coverage, trunk-based is risky. Bad code merges to main; production breaks. Invest in tests before going trunk-based.
Required for in-progress features. Build the flag system before relying on it.
Fast turnaround required. Hour or two, not days. May require culture change.
CI/CD that gates main. Required. Branch protection rules.
For teams moving from GitFlow:
The cultural shift takes longer than the technical shift.