Resolving Git Conflicts

Core rule: diagnose before you resolve. A conflict is a symptom, not the problem. Editing conflict markers is the right treatment only for genuinely divergent edits. A large class of conflicts — especially in stacked-branch workflows — are phantom conflicts created by squash merges, rebased or force-pushed upstreams, or otherwise duplicated commits. Hand-resolving those re-applies work that already landed, pollutes history with bogus merge commits, and frequently reintroduces stale code. When the cause is structural, the right fix is to abort and re-approach with a different strategy, after which most conflicts simply don't exist.

Work through the phases in order. Phases 1–2 are read-only and cheap; they determine everything else.

Autonomy policy: act without asking for confirmation, including aborting the in-progress operation and rewriting local history — the safety snapshot plus the reflog make this fully recoverable. The single exception: if the fix rewrites commits that were already pushed, finish the work locally, then stop and ask the user before any force-push, and use git push --force-with-lease (never bare --force).

Phase 0 — Safety snapshot

Before changing anything, record where things stand so any outcome is recoverable:

git status                          # full picture of the conflicted state
git stash list                      # note pre-existing stashes; never clobber them
# Back up the pre-operation branch tip:
git branch conflict-backup-$(date +%s) ORIG_HEAD 2>/dev/null \
  || git branch conflict-backup-$(date +%s) HEAD