Comparison
Feature branchvsTrunk-based development
Feature branch
you worked on a branch for three weeks and spent two days merging it.
Developing a change in isolation and integrating when it is finished. It is the default in most teams and it is defensible for small, short-lived changes; what it costs is proportional to duration, because the branch and the mainline diverge every day. The argument against it is never about branching itself, it is about integration frequency, which is why the same team can use branches and still practise continuous integration if they merge daily.
Full entry →Trunk-based development
everyone merged to main at least once a day, and the branch was never more than a few hours old.
Everyone integrates into one shared branch continuously, with incomplete work hidden behind flags rather than isolated on a branch. It makes merges trivial by making them constant, and it is the practice most strongly associated with high delivery performance in the DORA research. It requires real discipline elsewhere: tests you trust, feature flags, and the ability to hide unfinished work in production.
Full entry →