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, 91 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
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 | |
|---|---|---|---|
git checkout maingit 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. | ||
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 | ||
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 | ||
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 | ||
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. | ||
Feature split into 3 separate PRs of < 200 lines each, merged independently | Decomposing work into small, independently releasable units reduces merge conflict surface area and shortens feedback loops. | ||
CI/CD pipeline runs continuously; no planned "stabilization sprints" | • DORA identifies code freeze periods as a direct negative predictor of delivery performance • TBD eliminates the need for them | ||
main, plus at most 2 in-flight short-lived branches | • Atlassian and DORA both recommend this limit • more active branches signal drift toward long-lived branch anti-patterns | ||
# run full test suite locally before pushnpm test && git push | • All developers run compile + unit + integration tests on their workstation before pushing • CI is a safety net, not the first check |