Trunk-Based Development and Branching Strategies Cheat Sheet

Updated 2026-05-23

Next Topic: Value Stream Mapping Cheat Sheet

Trunk-based development (TBD) is a source-control branching model in which every developer integrates their work into a single shared branch — called trunk, main, or mainline — multiple times per day, resisting pressure to create long-lived parallel branches. DORA research consistently identifies TBD as a key capability of high-performing engineering teams, directly enabling continuous integration and continuous delivery. The critical insight practitioners must internalize is that branching strategy is not just a technical choice but a workflow contract: it determines merge frequency, feedback latency, conflict cost, and ultimately how quickly working software reaches users.

What This Cheat Sheet Covers

This topic spans 15 focused tables and 100 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Trunk-Based Development PrinciplesTable 2: Branching Strategies ComparedTable 3: Short-Lived Branches vs. Long-Lived BranchesTable 4: Feature Flags as Enablers of Trunk-Based DevelopmentTable 5: Commit Conventions and Changelog AutomationTable 6: Branch Protection Rules and Required ChecksTable 7: Merge Queues and Merge TrainsTable 8: Stacked Pull Requests and Stacked DiffsTable 9: Release Branch Patterns and Hotfix WorkflowsTable 10: Monorepo vs. Polyrepo Branching ConsiderationsTable 11: CI/CD Integration with Trunk-Based DevelopmentTable 12: Code Review Practices for Trunk-Based DevelopmentTable 13: Common Anti-Patterns in Branching StrategyTable 14: Scaled Trunk-Based Development for Large TeamsTable 15: Tooling Ecosystem for Branching Strategies

Table 1: Core Trunk-Based Development Principles

The foundational rules of trunk-based development define what distinguishes it from all branch-heavy workflows. Understanding these principles is the prerequisite for choosing or adapting any branching strategy for your team.

Concept	Example	Description
Single shared trunk	`git checkout main` `git commit -m "feat: add payment handler"` `git push origin main`	• All developers integrate work into one branch (`main`/`trunk`) • the trunk is the only long-lived branch, always kept releasable.
Commit to trunk at least daily	`git push origin main # at least once per 24 h`	• DORA data shows high-performing teams merge to trunk at least once per day • this keeps code current and eliminates integration debt
Keep trunk always green	CI pipeline triggered on every push; broken build = stop and fix immediately	• The trunk must be deployable on demand at any commit • a failing build is treated as a top-priority incident, not a normal state
Short-lived feature branches (≤ 2 days)	`git checkout -b fix/JIRA-42` # work, then merge back in < 2 days `git push origin fix/JIRA-42`	• Branches used for code review and CI validation only — never for long development cycles • one developer, one branch, deleted after merge
Direct-to-trunk commits (small teams)	`git commit -m "refactor: extract logger util"` `git push origin main`	Teams of ~15 or fewer can commit directly to trunk, bypassing PRs entirely if CI passes locally first.

Table 1: Core Trunk-Based Development Principles

Concept	Example	Description
Single shared trunk	`git checkout main` `git commit -m "feat: add payment handler"` `git push origin main`	• All developers integrate work into one branch (`main`/`trunk`) • the trunk is the only long-lived branch, always kept releasable.
Commit to trunk at least daily	`git push origin main # at least once per 24 h`	• DORA data shows high-performing teams merge to trunk at least once per day • this keeps code current and eliminates integration debt
Keep trunk always green	CI pipeline triggered on every push; broken build = stop and fix immediately	• The trunk must be deployable on demand at any commit • a failing build is treated as a top-priority incident, not a normal state
Short-lived feature branches (≤ 2 days)	`git checkout -b fix/JIRA-42` # work, then merge back in < 2 days `git push origin fix/JIRA-42`	• Branches used for code review and CI validation only — never for long development cycles • one developer, one branch, deleted after merge
Direct-to-trunk commits (small teams)	`git commit -m "refactor: extract logger util"` `git push origin main`	Teams of ~15 or fewer can commit directly to trunk, bypassing PRs entirely if CI passes locally first.