Last week’s post, Don’t wait until it’s ready to merge, got a lot more attention on social media than I’m accustomed to. Most of it was positive and supportive. But a small number of people jumped in to point out that continous integration isn’t the only way to avoid merge conflicts.

The argument was that continuously merging mainline into your own long-lived feature branch achieves the same benefit.

But does it?

TL;DR; No. It doesn’t.

There is often a benefit in tracking a changing mainline in your local branch. It can be easier to incrementally update your code to track one day’s worth of mainline changes at a time, than three weeks all at once. Although even this benefit is made completely obsolete by continuous integration. And in fact, it often increases the number of conflict resolutions you must do, as any section of code with multiple changes applied in sequence bust be resolved individually, rather than only once at the end.

Every conflict is the result of two developers working on the same code in the same time window. Simply re-ordering it, or adding rules about “conflict etiquette” doesn’t resolve the problem. The only way to reduce conflicts is to recude this time window. This is what Continuous Integration does.

If you’d like more details, I wrote 1600 words on the topic: Avoid merge conflicts, don’t manage them.