Trunk-based development
Trunk-based development is a source-control workflow where engineers integrate small changes to a single shared branch (trunk / main) at least once per day, gated by automated tests and feature flags rather than long-lived branches. It's the workflow that enables continuous delivery — high deploy frequency requires short-lived branches that don't drift from main.
Trunk-based development contrasts with git-flow's long-lived branches (develop, feature, release) that can accumulate weeks of drift before merging. The trade-off: trunk-based requires strong test automation + feature flags to gate incomplete features, but produces dramatically smaller PRs and faster delivery cycles. Most teams with daily-or-better deployment frequency use trunk-based development; teams with quarterly releases more often use git-flow.
Long-form posts that explore trunk-based development in depth — when to use it, common failure modes, how AI helps.
Related terms
- Continuous deployment
Continuous deployment automatically deploys every change that passes the test suite into production — no human gate between merging code and serving traffic.
- Feature flag
A feature flag is a runtime toggle that gates whether a code path is active.
- Pull request
A pull request (PR) — also called a merge request in GitLab / Bitbucket — is a proposal to merge changes from one git branch into another, typically with code review and CI checks gating the merge.