Skip to content
All insights
EngineeringProcess5 min read

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.

Most operations are behind where they could be.

Book a strategy call. We'll map one system worth automating in the next 30 days. No pitch, just the plan.