The Software Scrutiny Journal

We all dislike merge conflicts. Even worse, convoluted merge conflicts that when improperly resolved, lead to regressions. What is the best action towards transforming a codebase into easy-to-resolve (or zero) conflicts? I argue for Separation of concerns.

The Clean Code Blog quotes a publication from 1972 by David L. Parnas:

We propose … that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.

Consider the implications in regards to merge conflicts. If a module has only one reason to change, how often is it that two concurrent pull requests collide? Likely never. Moreover, any possible merge conflicts would be much easier to resolve.

Most common, deeply nested code can be a source for messy merge conflicts. Next time one is encountered, maybe try abstracting each bit out into a module. Just make sure that the module encasulates a singular design decision.