How I Rescued a Six‑File Git Merge Conflict in Three Simple Steps

The panic of a six‑file merge conflict

On a Wednesday afternoon the author merged a feature/refactor branch into main. Git reported six conflicted files, each marked with red UU indicators. The product manager was pressing for a release, and the instinctive reaction was to git reset --hard to the state from that morning.

Why manual editing is risky

Traditionally, developers open each conflicted file, locate the <<<<<<< markers, and edit manually. The author recounts a past incident where two teammates edited the same file, leading to hours of manual resolution and test failures because the merged logic mixed old and new code.

Step 1 – Identify conflicted files

Instead of scanning git status, a single command lists only the files that need attention: git diff --name-only --diff-filter=U The output shows the six files:

app.py
config.py
db.py
models.py
routes.py
utils.py

Step 2 – Choose the desired version

Git provides two shortcuts: --theirs (the incoming branch) and --ours (the current branch). Because the refactor branch contains the needed changes, the author uses --theirs for all files:

git checkout --theirs app.py config.py utils.py db.py routes.py models.py
git add app.py config.py utils.py db.py routes.py models.py

Each file is updated with a single line “Updated 1 path from the index”, eliminating any need to open an editor.

Step 3 – Commit the merge

After the conflicts are resolved, Git can commit directly:

git commit -m "merge: 合并feature/refactor,全部采用重构版本"

The whole process—from seeing six red files to a successful commit—takes less than 30 seconds, compared to the two hours the author previously spent on similar manual fixes.

Manual editing vs. command‑line automation

An intern once spent an hour and a half fixing five conflicted files manually in VS Code, only to cause three test failures because the manual removal of conflict markers merged incompatible function signatures. Running git checkout --theirs resolved the same five files in two seconds, illustrating the efficiency gap.

Recovering a mistakenly deleted branch

When a colleague accidentally deleted an unmerged feature branch with git branch -D, the author used git reflog to locate the commit hash: git reflog --oneline Finding the relevant hash (e.g., b826397), the branch is restored with: git branch feature/payment b826397 Reflog retains entries for 90 days, so branches deleted within that window can be recovered.

Stash pitfalls

If git stash is used before switching branches and later forgotten, the stash list can be inspected with git stash list to verify that the changes are still stored. The author recovered code from a stash that had been presumed lost.

Three essential takeaways

Run git diff --name-only --diff-filter=U first to list conflicted files instead of sifting through git status.

Use git checkout --theirs or --ours to batch‑apply the desired version, avoiding manual marker removal.

If a branch is deleted, locate its commit via git reflog and recreate it with git branch <name> <hash>. Remember that reflog entries expire after 90 days.

These commands have become muscle memory for the author, proving that solid fundamentals outweigh flashy tricks.