Trunk-Based Dev
Trunk-based development: short-lived branches, frequent integration, feature flags. The shape that keeps teams shipping daily.
Git — trunk-based development
EXAMPLE
# ===== The model =====
# - One main branch (trunk / main)
# - Feature branches live < 1 day; merge to trunk many times per day
# - Releases cut from trunk via tags or release branches
# - Feature flags decouple deploy from release
# Compared with GitFlow (long-lived develop / release / hotfix branches),
# trunk-based reduces merge conflicts + integration risk.
# ===== Daily flow =====
git checkout main
git pull --ff-only
git switch -c feature/add-tax
# ... small change ...
git add -p
git commit -m 'feat: add tax field'
git push -u origin feature/add-tax
# Open PR; reviewer merges; branch deleted.
# Repeat several times a day.
# ===== Branch protection =====
# GitHub: Settings -> Branches -> main
# - Require PR + reviews
# - Require CI checks
# - Linear history (no merge commits, only squash / rebase)
# - Require up-to-date branch before merge
# ===== Merge strategies =====
# Squash: collapses PR commits to one on main; cleanest history
# Rebase: keeps PR commits; linear history
# Merge commit: preserves branch shape; can clutter history
# Pick one strategy as a team and enforce.
# ===== Feature flags =====
# Code merged to main behind a flag; turned on for users when ready.
if (flags.isEnabled('tax-2024')) {
applyTax();
}
# Tools: LaunchDarkly, Unleash, OpenFeature, Flagsmith, ConfigCat.
# ===== Release cadence =====
# Continuous Delivery: every green main builds an artifact; deploy on demand
# Continuous Deployment: every green main deploys to prod automatically
# Releases via tags:
git tag -a v1.2.0 -m 'Release v1.2.0'
git push --tags
# Or via release branches (only for hotfixes / minor backports):
git switch -c release/1.2 main
# Backport fixes here; merge to main when stable.
# ===== Avoid =====
# - Long-lived feature branches (> 1 week)
# - Wide-ranging refactors landed in one PR
# - Manual integration phases ('feature freeze')
# - Merging without CI green
# ===== What it requires =====
# - Fast CI (< 10 minutes)
# - Strong test coverage
# - Feature flags
# - Code review culture
# - Trust + small PRs
# ===== Compared with GitFlow =====
# GitFlow: master, develop, feature/*, release/*, hotfix/*. Designed for scheduled releases.
# Trunk-based: main + short feature branches. Designed for continuous delivery.
# ===== Patterns =====
# - PRs < 400 lines diff
# - Merge to main 1+ times per dev per day
# - Feature flags for in-progress work
# - 'Boy scout rule': leave the code better than you found it
# ===== Pitfalls =====
# - Trunk-based without flags -> half-finished features ship
# - Slow CI -> people batch commits
# - No code review culture -> quality drops with frequency
# - 'Squash and merge' on big PRs -> history becomes opaque
Why it matters
Trunk-based development: short-lived branches, daily merges, feature flags. Pair with fast CI, strong tests, and a clear merge strategy. The win is fewer integration nightmares and faster shipping; the cost is investment in flags + tests up front.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
# Everyone commits to main; short-lived branches; feature flags. # CI catches breakage fast.Try it Yourself »
Discussion
Loading…