iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

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…