Trunk-based vs everything else (in practice)
The trunk-based debate is mostly resolved in theory. In practice, most teams are running a confused hybrid that has the disadvantages of both approaches.
Trunk-based development — everyone commits to main, behind feature flags, small frequent merges — has won the theoretical argument. In practice, most teams are running something that looks like trunk-based but isn't really, with long-lived feature branches that defeat the point.
What it actually requires
- Small commits — under a day's work, ideally.
- Feature flags that are real — not just hidden routes.
- CI fast enough that merging multiple times a day is painless.
- A culture that doesn't punish small, incomplete commits.
Why teams revert to feature branches
Slow CI. Feature flag infrastructure that's hard to use. Code review processes that punish small PRs. Each of these makes the path of least resistance the long-lived branch, even when the team's stated process is trunk-based.
Trunk-based isn't a process; it's an outcome of having the right supporting tools and culture.