Trunk-Based Development

About

Trunk-Based Development (TBD) is a software development strategy where all engineers integrate their code changes into a single shared branch, usually called main, master, or trunk, frequently — often multiple times a day.

Unlike traditional workflows that use long-lived feature branches, TBD promotes:

• High frequency of integration

• Minimal divergence from main

• Fast feedback loops

• Reduced risk of integration conflicts

TBD is more than just a Git practice — it's a cultural and architectural approach to software delivery that aligns with modern methodologies like Agile, CI/CD, DevOps, and Lean.

Historical Context

The Problem It Solves:

• In older workflows (e.g., Git Flow), developers often worked on long-lived branches, sometimes for weeks or months.

• This led to “merge hell” — massive, error-prone merges.

• Bugs and regressions would often surface late in the development cycle, right before release.

• Teams spent significant time rebasing or resolving conflicts, rather than building features.

TBD emerged as a response to this, especially as:

• CI/CD became mainstream.

• Agile and Lean advocated for short feedback cycles.

• Companies needed to release faster without breaking things.

Real-World Adoption Examples

• Google: 1 billion files in a monorepo; all developers commit to main.

• Facebook: Large-scale trunk-based dev with feature flags and monorepo tooling.

• Netflix: Fast iterations and releases using trunk-based workflows with extensive testing.

• Amazon: Microservices architecture with small teams committing directly to main.

Key Principles

a. Single Source of Truth

Everyone commits to a single branch (main) or integrates their work into it continuously. This is the authoritative version of the codebase.

b. Short-Lived Branches

If branches are used (e.g., for pull requests), they:

• Are created for a specific task.

• Stay alive for less than a day.

• Are merged immediately after code review.

c. Continuous Integration

Every commit to main triggers:

• Build automation

• Unit/integration testing

• Linting, formatting, static analysis

Failing commits are not allowed to remain in main.

d. Feature Flags

TBD discourages holding back features in branches. Instead:

• Incomplete features are deployed behind feature toggles, allowing:

  • Safe integration

  • Controlled releases

  • Easy rollback

• This enables continuous deployment without waiting for feature readiness.

e. Always Deployable

main must be always in a releasable state, even if not all features are user-visible. Teams can release at any moment with confidence.

Implementation Guidelines

Development Practices

• Break work into small, incremental, testable commits.

• Prefer pair programming or mob programming to align faster.

• Use code reviews to ensure quality, but avoid blocking progress for days.

Branching Strategy

• If needed, use short-lived branches like feature/login-fix or bug/checkout-null.

• Avoid feature branches that live more than 1–2 days.

Integration Strategy

• Use pull requests or direct commits (if the team agrees).

• Use squash merges to keep history clean.

• Use CI gating to prevent broken code from entering main.

Testing Strategy

• Cover critical logic with unit tests.

• Automate integration and end-to-end tests in the CI pipeline.

• Make tests fast, reliable, and idempotent.

When to use Trunk-Based Development & when not to use it ?

Factor / Topic	When to Use TBD	When Not to Use TBD
Team Size	Small to medium-sized teams (up to ~50 developers) that collaborate closely.	Very large teams (>100 developers) without proper tooling or coordination.
Release Frequency	Need to deliver changes multiple times a day or week (continuous delivery).	Long release cycles (months or quarters) with heavy regulatory controls.
Codebase Complexity	Modular or well-architected codebases that support frequent integration.	Monolithic legacy codebases with fragile dependencies and no modularity.
CI/CD Maturity	Established automated build, test, and deploy pipelines.	Lack of automated testing or deployment infrastructure.
Feature Size	Small, incremental, testable changes and features.	Large, complex features requiring prolonged development and integration.
Risk Tolerance	Teams willing to manage risk with feature flags and automated tests.	Teams needing guaranteed zero-risk merges (e.g., safety-critical systems).
Development Culture	Collaborative culture emphasizing fast feedback and shared ownership.	Silos between developers, QA, and operations or resistance to frequent integration.
Branching Discipline	Teams disciplined enough to create short-lived branches if any.	Teams that prefer long-lived feature branches and infrequent merges.
Tooling Support	Modern Git workflows with robust code review and CI tools.	Limited or outdated tooling, manual testing, or lack of code review enforcement.
Deployment Model	Continuous deployment or frequent releases (daily/weekly).	Strict release windows and manual, scheduled deployments only.
Testing Strategy	Strong automated unit and integration test coverage.	Lack of tests or heavy reliance on manual testing.