Comparison
Feature branchvsLong-lived branch
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 →Long-lived branch
the migration branch was six weeks old and the merge conflicts were in files neither change was about.
A branch that lives long enough for the mainline to move substantially underneath it. The pain grows faster than the branch's age, because conflicts multiply and the reviewer eventually faces a diff too large to read honestly. It is the strongest practical argument for branch by abstraction: big changes still need to be integrated in small pieces, whatever the size of the change.
Full entry →