Feature Branches vs. Trunk-Based Development

Feature Branches vs. Trunk-Based Development

Across various projects, I have experienced two very different patterns for developing unfinished features.

  1. Heavy Feature Branching (Gitflow, etc.) You work in a copy of the code until “everything is finished” and then merge, often only after QA and various quality checks. In practice, this quickly becomes expensive with multiple developers:
  • The longer a branch lives, the more likely and painful merge conflicts become, especially when people are working on the same files in parallel.
  • Two features in separate branches are tested individually, but never together. You only see whether A and B work together when they are merged.
  • Deployments become major events: complex, error-prone, and extremely time-consuming. One behavioral effect I have observed: If QA is waiting before the merge anyway, people sometimes become less diligent about their own testing because “QA will find it.”
  1. Trunk-Based Development + Continuous Integration Here, you minimize the amount of time that multiple versions of the code exist in parallel. The goal is to integrate into the trunk frequently, ideally at least daily, with as much automated testing as possible on the integrated version. This requires a change in mindset: smaller changes, faster feedback loops, and less friction caused by prolonged divergence.

What experience have you had with Feature Branches or Trunk-Based Development? What was decisive for your team?

More technical insights

Read more practical project insights on the blog.