Conflicts

Read a conflict, resolve it deliberately, and finish the merge.

09of 16
≈ 12Min read
5Parts

A conflict is not an error

Git merges by comparing both sides against the merge base. When both sides changed the same lines differently, there is no rule that can decide which is right — so git stops, writes both versions into the file, and hands it to the only thing that knows: you.

Nothing is broken and nothing is lost. The repository is in a paused merge, and every command still works.

The markers

Between <<<<<<< and ======= is your side — the branch you are on. Between ======= and >>>>>>> is theirs — the branch being merged in, named on the last line. Resolving means editing that block into the text you actually want and deleting all three marker lines.

The answer is often neither side exactly. Two people changed the same function for different reasons; the resolution usually has to do both jobs.

what the file looks like
<<<<<<< HEAD
Vesper 890
=======
Vesper 910
>>>>>>> autumn-prices

The loop

start to finish
git merge autumn-prices
# CONFLICT (content): Merge conflict in price-list.md

git status              # "Unmerged paths" lists exactly which files
# …edit the files…
git add price-list.md   # adding is how you say "this one is resolved"
git status              # nothing unmerged left?
git commit              # finishes the merge, with both parents

git merge --abort       # or: put everything back as it was
git add means resolved

Git does not check whether you deleted the markers. Staging a file with <<<<<<< still in it commits the markers — and that is how they end up in production. Search for <<<<<<< before you commit; most editors will show them for you.

Taking one side outright

when one side is simply right
git checkout --ours   price-list.md     # keep your branch's version
git checkout --theirs price-list.md     # keep the incoming version
git add price-list.md

# and for a whole merge, decided up front
git merge -X ours autumn-prices         # prefer our side in every conflict
ours and theirs flip during a rebase

A rebase replays your commits onto their branch, so "ours" is the branch you are rebasing onto and "theirs" is your own commit. It is confusing exactly once, and then you remember to check.

How to have fewer of them

  • Short branches. Divergence is the raw material of conflicts.
  • Pull, or rebase onto main, often — several small conflicts instead of one enormous one.
  • Agree on formatting once, with a formatter. A reformatted file conflicts with everything.
  • Do not reorder or reformat unrelated code in a feature branch.
  • git config --global rerere.enabled true — git remembers how you resolved a conflict and reapplies it if the same one comes back. Worth it during a long rebase.

Practice

Next →Rebase