Resolving a complicated multi-file merge conflict is a process of isolating each conflicting file, understanding both sides' intent, and carefully reconciling the changes so the final code is functionally correct and consistent.
Key Points: • A visual merge tool (git mergetool) makes it much easier to compare the base, "ours," and "theirs" versions side by side than reading raw conflict markers. • Working through conflicts file by file, rather than all at once, keeps the review focused and reduces mistakes. • Talking directly with the other contributors clarifies intent when it isn't obvious from the diff alone, which prevents silently discarding someone's fix. • After all conflicts are resolved, running the full test suite (not just a quick smoke test) is essential before finalizing the merge, since manual resolution is error-prone. • Frequent, smaller merges going forward reduce the chance of this kind of large, tangled conflict recurring.
Example: Two developers both refactored overlapping parts of an OrderService and a PricingService at the same time; using git mergetool to walk through each file and confirming intent with both authors kept the merge accurate instead of guessing which version was "right."
Interview Tip: A concise interview answer is:
"I use a visual merge tool to work through conflicts file by file rather than guessing from raw markers, and I talk to the other contributors to understand their intent when it isn't obvious. Once everything's resolved, I run the full test suite before finalizing the merge, since manual conflict resolution is easy to get subtly wrong."