CodeOath
← All posts
Git65 min total · 17 parts

Git Internals and Workflows: Branching, Merging, and Rebasing

Contents — Part 7 of 17: Resolving a Merge Conflict
Part 7 of 17 · ~1 min

Resolving a Merge Conflict

A conflict happens when Git can't automatically decide which of two changes to keep on the same lines of the same file — it never guesses; it stops and asks you to decide. Git marks the disagreement directly inside the file:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature

Everything between <<<<<<< HEAD and ======= is the version from the branch you're merging into (your current checkout); everything between ======= and >>>>>>> feature is the version coming from the branch you're merging in. Edit the file down to the version you actually want — deleting the conflict markers entirely, they aren't valid code or syntax on their own — then:

git add <the resolved file>
git commit          # completes a merge conflict's resolution

git status during an unresolved conflict lists exactly which files still need attention, and most editors' Git integrations render the conflict markers with inline "accept current/incoming/both" actions rather than requiring you to hand-edit the markers — but understanding what the markers actually mean is what makes those editor shortcuts trustworthy rather than magic.