4 ms·
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 insurmo
by c7DJTLrn 6y ago
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 6y agoSorry, 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 6y agoI 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"?