Trunk-Based Development: how to use it, branch, and release
Post by
Damian Sibiński
Published
23 February 2025
Trunk-Based Development (TBD) is a version control strategy where the team works on a single main branch — the trunk (often main or master). All changes land there quickly, and feature branches live short (hours, at most 1–2 days). Unlike Git Flow, there are no long-lived branches like develop, release, or feature/big-feature.
The key idea: small, frequent commits to trunk, fast merging, and continuous integration. Every merge must pass CI (build, tests). Releases are created by tagging specific commits on trunk or via release branches.
Trunk-Based Development is not chaos — it's discipline: small changes, fast feedback, continuous integration, and no long-lived branches.
How to branch?
Create a short-lived feature branch from trunk, work on a small, atomic change (1–2 days max), rebase on trunk often (or merge trunk into yours), and when CI is green — merge to trunk and delete the branch. Don't keep branches for weeks. If a feature is large, split it into smaller PRs. Branch naming: feature/short-name, fix/bug-id — keep names short.
How to release?
A release is simply a version of trunk at a given moment. Options: 1) Tagging — git tag v1.2.3 on the commit you build from. 2) Release branch (optional) — short-lived release/v1.2.3; 3) Continuous deploy — every merge to trunk goes straight to production (if you have feature flags and solid CI/CD). Key point: trunk is always in a release-ready state.
Feature flags — why?
Feature flags let you merge incomplete code to trunk but enable it only for selected users or environments. Benefits: you don't block others, you avoid long-lived branches, you can test in production gradually (canary, A/B), and you can turn off a feature without a rollback. Use them for large features split across many PRs — each PR merges immediately, but the feature stays off until it's ready.
What to watch out for?
1) CI must be fast — a slow pipeline discourages frequent merges. 2) Trunk must always be green — a broken build blocks everyone. 3) Small PRs — easier to review and merge. 4) Frequent rebase/merge from trunk — avoid big conflicts. 5) Pair programming and code review — with frequent merges, quality matters. 6) Feature flags — keep them tidy, remove them after rollout.
Pitfalls
Lack of discipline — long branches, rare merges. Slow CI — developers avoid merging. Broken trunk — one bad commit blocks the whole team. Too many flags — technical debt, hard to remove. No tests — merging without confidence that nothing breaks. Team not used to it — requires a culture and tooling shift.
Strengths
Fewer merge conflicts — small changes, frequent sync. Faster feedback — bugs surface in CI immediately. Simpler model — no complex Git Flow. Easier code review — smaller PRs. Continuous integration in practice — trunk always up to date. Faster releases — any commit can go to production.
Use cases
Startups and small teams — fast iteration, simple workflow. Projects with CI/CD and automation — TBD requires a good pipeline. Teams of 2–10 people — scales well with discipline. Products with frequent releases — web apps, SaaS, microservices. Projects with feature flags — LaunchDarkly, Unleash, custom — ideal combination. Avoid TBD when: distributed team without solid CI, regulations require long release cycles, no culture of small changes.
Loading comments…