Trunk-Based Development — Explained with Examples

Trunk-Based Development uses short-lived feature branches merged frequently into main, minimizing branching complexity and merge overhead.

Trunk-Based Development (TBD) is a branching model where all developers work on a single branch called the trunk (usually main). Feature branches, if used at all, last no more than a day or two. Developers commit directly to trunk or merge small branches multiple times daily. Continuous integration ensures the trunk stays green.

Think of Trunk-Based Development like valet parking. You hand your keys over briefly (short branch), the attendant parks the car quickly (merges to trunk), and within minutes you have your car back. Compare this to GitFlow, where your car might be in the shop (feature branch) for weeks before you see it again.

TBD eliminates the merge hell that arises from long-lived branches. Every developer integrates their changes continuously, catching conflicts early. This model pairs naturally with feature flags to hide incomplete work and with continuous deployment.

# Short-lived feature branch (hours, not days)
git checkout -b fix-typo main
git commit -m "Fix typo in README"
git checkout main
git pull
git merge fix-typo
git push
# Branch is deleted after merge

TBD requires strong CI discipline. Without automated tests running on every commit, frequent merging can introduce instability. Teams typically use feature flags to gate incomplete features.

GitFlow, GitHub Flow, Branch, Merge, CI/CD

GitHub Flow Comparison