Resolving Real Merge Conflicts Under Pressure

In one line

A genuine multi-file conflict during a time-sensitive merge is where Git skills actually get tested — a calm, systematic process beats panic every time, and knowing the escape hatches removes most of the pressure.

0/4 · 0%

Think of it like this

An actual kitchen fire versus a smoke alarm test — Topic 2.2 covered a single, deliberately-created conflict as a calm, controlled drill; this topic is about the real version, often several files at once, often under real time pressure (a release deadline, a broken shared branch blocking teammates). The mechanics are identical; what differs is staying systematic instead of panicking.

Key ideas

01
Before resolving anything, get ORIENTED: git status lists every conflicted file at once, and git log --merge (or checking git diff with no arguments) shows exactly what changed on each side. Resolving conflicts one file at a time, in a clear order, beats jumping between several half-resolved files at once.
02
For each conflicted file, understand BOTH sides' INTENT before touching anything — what was each change actually trying to accomplish? Sometimes the correct resolution is genuinely 'keep both' (two people added different, unrelated things to the same section), sometimes it's 'keep one side entirely,' and sometimes it's a genuinely new combination that correctly captures both intents — blindly picking one side without understanding the other risks silently discarding real, needed work.
03
git checkout --ours <file> or git checkout --theirs <file> resolves a conflict by taking one side ENTIRELY for that file — genuinely useful when you're confident one side is simply correct and the other should be fully discarded, but genuinely dangerous if used as a shortcut without actually checking what's being thrown away.
04
If a conflict resolution turns out to be wrong AFTER completing the merge, it's not a disaster — git revert on the merge commit (or, if not yet pushed, git reset back to before the merge and starting over) are both real, safe recovery paths. A bad merge resolution is a mistake like any other, not a uniquely unfixable one.
05
When multiple files conflict and the situation is genuinely confusing, git merge --abort (Topic 2.2) is always available as a full, clean escape hatch — it costs nothing to abort, take a breath, discuss with whoever made the conflicting change, and re-attempt the merge with a clearer plan, rather than pushing through a resolution you're not actually confident in.

Code & diagrams

real-conflict-checklist.shmarkdown

A repeatable sequence for a genuinely stressful, multi-file conflict.

# 1. Get oriented — see everything conflicted at once, don't dive in yet
git status

# 2. Work through files one at a time
git status | grep "both modified"

# 3. For each file, understand BOTH sides before editing
git diff HEAD -- path/to/file.java        # what your side changed
git diff MERGE_HEAD -- path/to/file.java  # what the incoming side changed

# 4. Resolve, then mark as done
#    (edit the file directly, removing all conflict markers)
git add path/to/file.java

# 5. When you're confident ONE side is simply correct for a whole file
git checkout --ours path/to/other-file.java
git add path/to/other-file.java

# 6. Once every file is resolved and staged
git status
git commit

# 7. If it turns out wrong afterward — not a disaster
git revert -m 1 <merge-commit-sha>   # -m 1 keeps the "main line" parent

# 8. If it's all going wrong mid-resolution — full clean escape
git merge --abort

Explain it without notes

Why is it risky to resolve a conflict by immediately picking 'ours' or 'theirs' without first understanding what each side was actually trying to do?

A merge you completed and pushed an hour ago turns out to have a wrong conflict resolution. Is this a serious, unrecoverable problem? What's the fix?

Practice

Set up a deliberate multi-file conflict (edit two different files across two branches, both touching the same lines) and practice resolving both, one at a time, using git status to track your progress.

Deliberately create a merge with an intentionally WRONG resolution, push it, then practice reverting that merge commit with git revert -m 1 and confirm the repository returns to a correct state.

Trade-offs

↔
Taking the time to genuinely understand both sides of every conflicted file is slower in the moment than reflexively picking one side and moving on — but a rushed, poorly-understood resolution under time pressure is exactly how real, sometimes serious bugs get silently merged into a shared branch, so the extra minutes spent understanding intent are almost always the better trade, even against a real deadline.

Done when you can

I have a systematic process for working through a multi-file conflict rather than jumping around randomly.
I understand the real risk of blindly using --ours or --theirs without checking what's being discarded.
I know a bad merge resolution is recoverable via revert, even after it's been pushed.