[c7DJTLrn]

Why are merge conflicts considered a problem? They're just git asking you what the source should really look like. They can be tricky to resolve but not insurmountable.

What this really looks like is a procrastination tool so that somebody can sit back and relax when they see someone else is changing the same area in the source.

I'd love to hear why I'm wrong.

[henryjcee]

Sorry, missed your reply to this. So this came out of the experience at my previous job where we were a big team working on a rapidly changing codebase and we reckon that resolving conflicts was taking anything from 5-10 engineer hours a week.

We tried quite a few processes to reduce it and they'd all work for a few weeks but inevitably we'd revert back to old behaviour pretty fast.

On your point about it being a procrastination tool, I'd love it if my team members took a minute to stop work and converse with the others if they're working on the same bit of code! Aside from time saved fixing a potential conflict it's probably indicative that a particular bit of the system needs to be refactored. Anything that can help guide the decision to refactor is probably a force for good but we'll see. H

[c7DJTLrn]

I see, apologies for my unnecessary hostility.

It makes sense that the tool would highlight parts of the codebase that need refactoring. I am a bit confused about what would be communicated between two engineers on a piece of code though. Would it be "hey, could you do XYZ as part of your change"? Or "hey, please don't change this piece of code until I've changed it"?