Chapter 4.3 — Trunk Based Development☕ 10 min read

Trunk Based Development

Short-lived branches, feature flags, aur CI/CD — yeh teeno chahiye Trunk Based ke liye. Bina CI/CD mat try karna, main toot jaayega!

01Trunk Based: Main Hi Sab Kuch Hai

Trunk Based Development is the simplest branching strategy with the hardest discipline: everyone commits to main frequently — at least once a day.

Short-lived feature branches are allowed, but they must live for less than 1 day (maximum 2 days). Create branch, commit, push, review, merge, delete. All in one sitting if possible.

There is no develop branch, no release branch, no hotfix branch. main is always deployable. Every commit on main should be production-ready.

Continuous Integration is MANDATORY — every push triggers an automated build + test pipeline. If the build breaks, fixing it is the team's #1 priority.

This is how Google, Meta, and Microsoft develop at massive scale. Thousands of engineers merging to main multiple times per day.

The key enabler that makes this possible: Feature Flags — they let you hide incomplete features in production.

# Trunk Based workflow
git checkout main
git pull origin main
git checkout -b feat/add-payment

# Work FAST (same day!)
echo "payment code" >> app.js
git add . && git commit -m "feat: add payment module"
git push origin feat/add-payment

# PR review (< 2 hours ideally)
# Merge to main same day
git checkout main
git merge feat/add-payment
git branch -d feat/add-payment

# Deploy immediately from main

Trunk Based = Auto rickshaw. Seedha, tez, simple. Main hi sab kuch hai. No detours, no long branches, no develop branch. Everyone drives on the same road. Speed is the game — deploy 10 times a day, not once a month.

02Feature Flags: Incomplete Code, Safe Production

Feature flags are the safety net that makes Trunk Based Development possible. They let you merge incomplete code to main without exposing it to users.

The pattern is simple: if (FLAGS.newDashboard) { renderNew(); } else { renderOld(); }. The new code exists in production, but nobody sees it until the flag is turned on.

Flags can be configured in several ways:

On/Off for everyone — simple boolean. All users see it or none do.
Percentage rollout — 1% of users see it, then 10%, then 50%, then 100%. Gradual and safe.
Per-user targeting — specific users, beta testers, internal employees only.

Popular tools: LaunchDarkly, Unleash, or simple custom config files and environment variables.

Without feature flags, Trunk Based doesn't work — you'd break production every time you merge incomplete work. Flags are not optional; they are a prerequisite.

Critical: Feature flags must be cleaned up after full rollout. Old flags = technical debt.

# Feature flag in code
if (process.env.ENABLE_NEW_PAYMENT === 'true') {
  renderNewPayment();
} else {
  renderOldPayment();
}

# Merge incomplete code safely
git checkout main
git merge feat/new-payment
# Code is in main but hidden behind a flag!

# Rollout gradually:
# 1% of users -> 10% -> 50% -> 100%
# Then remove the flag

💡 Pro Tip: Feature flags are NOT just for Trunk Based. Even in Git Flow, flags help with gradual rollouts and A/B testing. The difference is: in Trunk Based, flags are MANDATORY. In Git Flow, they are optional. If your team doesn't have a flag system, you're not ready for Trunk Based.

03Branch by Abstraction: Big Refactors

How do you refactor a core module over 2 weeks without creating a long-lived branch? Branch by Abstraction.

The pattern works in 4 steps:

Create an abstraction layer — an interface or wrapper around the old code. All callers now go through the abstraction.
Build the new implementation — write the replacement code behind the abstraction, hidden by a feature flag.
Switch traffic — use a feature flag to route some/all traffic to the new implementation. Test in production safely.
Remove the old implementation — once the new code is proven, delete the old code and the abstraction layer. Clean up the flag.

All work is merged to main incrementally. No 2-week-old branch. No massive merge conflict. Every step is a small, safe commit to main.

This is how Google replaces core infrastructure without stopping development. No feature freeze, no integration hell.

# Branch by Abstraction steps:

# Step 1: Create abstraction
# payment-service.js (abstraction layer)
# Calls old-payment.js underneath

# Step 2: Build new implementation
# new-payment.js (behind feature flag)

# Step 3: Switch traffic
# payment-service.js now calls new-payment.js
# when flag is on

# Step 4: Cleanup
# Remove old-payment.js and the flag

Branch by Abstraction is the "secret weapon" of big tech. It lets you replace a database, swap an API, or rewrite a core module — all while the team keeps shipping features to main. No long-lived branches, no code freezes. Each step is a small, reversible commit.

04CI/CD is Non-Negotiable

Trunk Based requires CI/CD. Without it, you'll break main constantly. This is not a suggestion — it is a hard requirement.

Every push to main triggers: build, lint, unit tests, integration tests. If any step fails, the team stops everything to fix it.

Feature branches are also CI-tested before merge (via PR checks). A branch that fails CI cannot be merged.

Continuous Deployment: if CI passes on main, it auto-deploys to production. No manual steps, no approval gates, no "deploy Friday" anxiety — because every commit is small and safe.

Without CI, Trunk Based is just "pushing broken code to main faster." The automation is what makes frequent merges safe.

The rule: "If the build is red, nothing else matters." Broken main = highest priority. Everything stops until main is green again.

# CI/CD pipeline for Trunk Based
# .github/workflows/ci.yml
# on: push to main OR pull_request to main

# Steps:
# 1. Install dependencies
# 2. Lint check
# 3. Unit tests
# 4. Integration tests
# 5. Build
# 6. Deploy (if main branch)

# If CI fails on main, EVERYONE stops to fix it.
# "If the build is red, nothing else matters."

💡 Pro Tip: CI/CD maturity is a spectrum. You don't need 100% test coverage to start. But you NEED: automated build, automated test suite, and automated deployment. Start with what you have, improve over time. The CI/CD pipeline grows with your team's confidence.

05Git Flow vs Trunk Based: The Debate

Git Flow: structured, safe, slow. Designed for scheduled releases. Multiple long-lived branches (develop, release, hotfix). Good for teams that ship once a month.

Trunk Based: fast, requires discipline, CI/CD mandatory. Designed for continuous deployment. One branch (main) with short-lived feature branches. Good for teams that ship 10 times a day.

You cannot switch to Trunk Based overnight — it requires CI/CD, feature flags, and team discipline. These are prerequisites, not nice-to-haves.

Most teams start with GitHub Flow (main + PRs, no develop branch) and evolve to Trunk Based when their CI/CD and feature flag systems are mature enough.

Hybrid approach: Use Trunk Based for most work, but create release branches for special events (major version launches, compliance audits). This is practical and common.

# Choosing your strategy:
# 1-2 developers, fast iteration: GitHub Flow
# Large team, scheduled releases: Git Flow
# Large team, continuous deployment: Trunk Based

# Most teams are somewhere in between.
# Start simple (GitHub Flow) and add
# complexity only when needed.

# Don't adopt Trunk Based just because
# Google uses it.
# Adopt it when your CI/CD and feature flag
# system is mature enough.

Git Flow = traditional Indian wedding. Grand, structured, takes weeks of planning. Trunk Based = auto rickshaw. Quick, direct, gets you there fast. Different tools for different speeds. Don't use a wedding procession when you need an auto — and don't take an auto when you need a baraat.

Lo kar liya — Key Points:

✅ Trunk Based Development means everyone commits to main frequently with short-lived branches (less than 1 day)
✅ Feature flags hide incomplete code in production, making safe merges to main possible
✅ Branch by Abstraction enables large refactors without long-lived branches
✅ CI/CD is mandatory — every push triggers build and test, broken main stops all work
✅ Trunk Based is for continuous deployment; Git Flow is for scheduled releases
✅ Don't adopt Trunk Based until your CI/CD and feature flag systems are mature

Previous4.2 — Git Flow Strategy 📋 All Chapters Next Chapter4.4 — Branch Naming Conventions →