Comparison
Branch by abstractionvsLong-lived branch
Branch by abstraction
you put an interface in front of the old code, added the new one behind the same interface, and switched with a flag.
Making a large change on the main branch by introducing an abstraction over the existing implementation, building the replacement behind it, and switching over. It exists because the alternative — a long-lived branch for a big migration — reliably ends in a merge nobody can review. The abstraction is temporary and should be removed once the old path is gone, which is the step most teams forget.
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 →