Resolving merge conflicts

Conflicts surface when the 3-way merge (base, ours, theirs) can't combine non-overlapping changes — i.e., both 'ours' and 'theirs' modified the same hunk relative to the common ancestor. Git writes both versions into the file with conflict markers and adds the file to the index in 'unmerged' state (stage 1=base, 2=ours, 3=theirs).

Conflict marker format: default style shows ours / theirs only. git config merge.conflictstyle diff3 adds the common ancestor (a 3-way view) — much easier to understand 'what was the original, what did each side change'. zdiff3 (Git 2.35+) is even tighter.

Resolution tools: git mergetool launches your configured merge.tool (vimdiff, kdiff3, meld, VS Code via git config merge.tool vscode). Pure-CLI: git checkout --ours <file> / --theirs <file> to take one side wholesale.

Status during conflict: git status lists 'Unmerged paths'. The file is in the working tree with markers, the index has 3 stages. After editing + saving, git add <file> collapses the 3 stages into stage 0 and removes the unmerged marker.

git rerere (reuse recorded resolution): once enabled (git config rerere.enabled true), Git remembers how you resolved a given conflict and auto-applies the same resolution next time the same conflict appears. Magical for long-running branches that rebase often.

Avoiding conflicts: pull/rebase frequently (small diff = small conflict surface), keep PRs short, agree on file/folder ownership in monorepos, format-on-save with the team's formatter to avoid whitespace conflicts.