Trunk-Based Development

The Hook (The "Byte-Sized" Intro)

Google, Facebook, and Netflix all deploy to production hundreds of times per day. Their secret? Trunk-based development. No long-lived branches. No "develop" branch. No release branches that live for weeks. Just one trunk (main), ultra-short-lived branches (hours, not weeks), and continuous integration. It's the simplest workflow that works at the largest scale.

📖 What is Trunk-Based Development?

Trunk-based development (TBD) is a branching strategy where all developers integrate their work into a single shared branch (main / "trunk") as frequently as possible — ideally multiple times per day. Feature branches exist but are extremely short-lived (hours to 1-2 days max).

Conceptual Clarity

Core principles:

Principle	Practice
One trunk	`main` is the only long-lived branch
Short-lived branches	Feature branches live hours to 1-2 days
Continuous integration	Every merge triggers automated tests + build
Small batches	Each PR is small (< 200 lines typically)
Feature flags	Incomplete features hidden behind toggles, not branches
Always deployable	`main` can be deployed at any time

How feature flags replace long branches:

Traditional:  feature/payment (lives 3 weeks) → big merge → deploy
TBD:          Small PRs deploy daily, code hidden behind:
              if (featureFlags.newPayment) { /* new code */ }

Real-Life Analogy

TBD is like a newspaper newsroom. Every journalist writes small articles and submits them to the editor (main) constantly throughout the day. Nobody holds their story for 3 weeks. The newspaper goes to print daily (deployment), so everything in the system must be print-ready at all times.

Visual Architecture

gitGraph commit id: "Deploy v1" branch feat-1 commit id: "Small fix" checkout main merge feat-1 id: "PR #1" branch feat-2 commit id: "Add button" checkout main merge feat-2 id: "PR #2" commit id: "Deploy v2" branch feat-3 commit id: "Update API" checkout main merge feat-3 id: "PR #3" commit id: "Deploy v3"

Why It Matters

Speed: Small, frequent merges mean features ship in days, not months.
Fewer conflicts: Branches that live hours rarely conflict with each other.
CI/CD native: Every merge is tested and potentially deployed.
Simplicity: No complex branch management, no release branches to maintain.

Code

bash

# ─── Trunk-Based Development daily workflow ───

# Morning: start from latest main
git switch main
git pull

# Create a tiny, focused branch
git switch -c fix/button-alignment

# Small change, commit, push
git add src/button.css
git commit -m "Fix button alignment on mobile"
git push -u origin fix/button-alignment

# Open PR → review → merge (same day)
gh pr create --title "Fix button alignment" --body "Closes #88"

# After merge: clean up
git switch main
git pull
git branch -d fix/button-alignment

# ─── Feature flags for incomplete work ───
# Instead of a long branch, merge daily behind a flag:
git add src/payment.js
git commit -m "Add payment step 1 (behind feature flag)"
# Code: if (flags.newPayment) { showNewPage() }

TBD vs Long-Lived Branches

Aspect	Trunk-Based	Long-Lived Branches
Branch lifespan	Hours to 1-2 days	Weeks to months
Merge frequency	Multiple times/day	Weekly or less
Conflict size	Tiny	Large and complex
Deploy readiness	Always	Only after big merge
Complexity	Simple	High (release branches, etc.)
Best for	SaaS, web apps, CI/CD teams	Packaged software, strict releases

Key Takeaways

Trunk-based development = one main branch + ultra-short-lived feature branches.
Merge small changes frequently — diffs measured in dozens of lines, not hundreds.
Use feature flags to deploy incomplete features safely behind toggles.
main must always be deployable — automated tests are non-negotiable.

Interview Prep

Q: What is trunk-based development? A: A branching strategy where all developers integrate into a single shared branch (main) frequently — often multiple times per day. Feature branches are extremely short-lived (hours to 1-2 days), and incomplete features are managed with feature flags rather than long-lived branches.
Q: How does trunk-based development handle incomplete features? A: Through feature flags. Code for incomplete features is merged to main but hidden behind toggles (if (flags.newFeature)). This way, the code is integrated and tested continuously but not visible to users until the flag is enabled.
Q: What are the prerequisites for trunk-based development? A: Strong automated test coverage (CI must catch regressions), small PR discipline (each change is tiny and focused), feature flag infrastructure, and a team culture of frequent integration. Without good CI, TBD quickly breaks main.