Recall from lesson 5-3 that during a true merge Git combines both branches automatically when they changed different files, or different lines of the same file.
In either case there is no ambiguity about the result, so Git can assemble it without asking anything.
That leaves exactly one case unhandled, both branches editing the same lines, and it is what this whole unit is about.
The one case Git can't decide
You changed line 2 of cake.txt on main. Your teammate's branch also changed line 2, differently. Merge them and Git faces two competing truths with no way to know which one you want. It refuses to guess:
$ git merge brown-butter Auto-merging cake.txt CONFLICT (content): Merge conflict in cake.txt Automatic merge failed; fix conflicts and then commit the result.
This is a merge conflict. Two things to internalize before anything else:
- Nothing is broken or lost. Both versions are safely in their commits. Git has simply paused the merge and is waiting for a human decision.
- Conflicts are routine. On a team they happen weekly. Senior engineers read the message and calmly fix it in two minutes, and by the end of this unit you will too.
Reading the conflict markers
Git rewrites the conflicted file to show both versions, fenced by marker lines. Opening cake.txt shows this.
Preheat oven to 180C <<<<<<< HEAD Add regular butter ======= Add brown butter >>>>>>> brown-butter Bake for 25 minutes
Decoding it line by line:
<<<<<<< HEADstarts your side, what the line looks like where you stand, meaningHEADand so the branch you are on, heremain.=======is the divider between the two versions.>>>>>>> brown-butterends their side, the incoming branch's version, labeled with that branch's name.- Everything outside the markers, the preheat and bake lines, merged fine and needs no attention.
The conflict is only the marked region, which is the fact that makes conflicts manageable. A 500-line file with one conflicted line needs one decision, not 500.
The markers are also just ordinary text now sitting in your file. Nothing enforces them, which means your editor will happily let you save them, and Git will happily let you commit them if you forget to take them out.
In a conflicted file, the ======= line separates your current branch's version, above it, from the incoming branch's version, below it.
Above the divider, starting at <<<<<<< HEAD, is HEAD's version, meaning the branch you are standing on. Below it, running down to the >>>>>>> line, is the version from the branch being merged in.
Your job is to replace the whole marked block, markers included, with the text you actually want. That framing matters: you are not choosing a side so much as writing the final version, which may be one side, the other, or a combination neither branch had.
The marker that begins your current branch's version is <<<<<<< HEAD.
It is seven < characters followed by HEAD, the name for your current position from lesson 3-1, which is what makes it identifiable as your side.
The other two complete the frame. ======= divides the two versions, and >>>>>>> closes the incoming side, followed by the name of the branch being merged in rather than by HEAD, since that branch is not where you are standing.