Topic 26

When Git Cannot Decide

Branching

Both branches changed the same lines of the same file. Git will not guess which version is right, so it stops, writes both versions into the file, and hands the decision to you.

That is a merge conflict. It is not an error, nothing is broken, and no work is at risk. It is the one moment in Git that genuinely needs a human, and it is worth going through slowly once so that the first real one is boring.

What triggers one

Conflicts need overlap. Two branches editing different files never conflict. Two branches editing different lines of the same file merge without comment. A conflict happens when both sides changed the same lines, and Git has no basis for preferring one.

On Sandpiper: on main you corrected the meeting time in the page header. On sightings-page you rewrote that same header entirely. Both changes are real, both are wanted, and Git cannot combine them for you.

What Git does

The merge stopping

git merge sightings-page

Git reporting the disagreement

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

The merge is paused, not abandoned. git status lists the affected files under unmerged paths, and everything that merged cleanly is already staged.

Reading the markers

Open the conflicted file and you will find both versions written into it, surrounded by markers:

index.html, as Git left it

<header>
<<<<<<< HEAD
  <p>The club meets on the first Thursday of every month at 7pm.</p>
=======
  <h2>Sandpiper Birdwatching Club</h2>
  <p>Monthly meetings, first Tuesday, 7pm. All welcome.</p>
>>>>>>> sightings-page
</header>

Three markers, and they are ordinary text sitting in your file. <<<<<<< HEAD opens your side — the branch you are standing on. ======= divides the two. >>>>>>> sightings-page closes the incoming side and names where it came from.

Neither version is marked as correct, because Git does not know which is.

Resolving it

Edit the file until it says what it should say. You may keep your side, keep theirs, or write something combining both — and combining is usually what you actually want:

The resolved header: the new heading, the corrected day

<header>
  <h2>Sandpiper Birdwatching Club</h2>
  <p>Monthly meetings, first Thursday, 7pm. All welcome.</p>
</header>

Every marker line must be gone. They are literal text, and a marker left behind ends up on your web page for everyone to see.

Tell Git it is settled, then finish the merge

git add index.html
git commit

Staging the file is how you say "this one is resolved". The commit completes the merge, and Git proposes a message describing it. Those are the four steps, start to finish.

A conflict, from stop to finish

CONFLICTmerge paused · git status names the files

→

Edit the filemarkers all gone

→

git addmark as resolved

→

git commitmerge complete

The escape hatch

If it looks worse than you expected, or you simply want to think about it later:

Undo the whole merge attempt

git merge --abort

Everything returns to how it was before you typed merge. No commit, no markers, no half-finished state. Knowing this command exists is what makes a first conflict survivable, so it is worth running once deliberately just to see that it works.

Keeping conflicts small

Conflicts scale with two things: how long a branch lives, and how much of the project it touches. A branch that exists for two hours and changes one file rarely conflicts with anything. A branch that has run for three weeks across twenty files will conflict with everything.

The prevention is not cleverness — it is short branches, merged often. That is also why Chapter 8's workflow keeps pieces of work small, and why a pull request that has been open for a month is a problem rather than a virtue.

Common Confusions

"A conflict means I did something wrong." It means two changes overlapped. It is the normal, expected cost of two branches — or two people — touching the same lines.
"Git will choose the newer change automatically." Git never chooses. Timestamps play no part; it stops and asks precisely because it has no basis for preferring either side.
"I can leave the markers in and commit." The markers are literal text in your file. Left in, they end up in the published page. Removing all of them is part of resolving.
"Once a conflict starts, I have to finish it." git merge --abort returns everything to before the merge, at any point before you commit.

Why It Matters

Conflicts are the most feared part of Git for beginners, and the fear is what makes people avoid branches entirely — which costs them everything branches are for.
This exact conflict returns in Chapter 8 as a team problem, so resolving it once alone and calmly is direct preparation for resolving it later with someone waiting.
Knowing the abort command changes the emotional shape of the whole operation: nothing here is a one-way door.

Knowledge Check

What causes a merge conflict?

Both branches changed the same lines of the same file in different ways
Both branches changed the same file, whatever lines each of them touched
One branch deleted a file that the other branch had already committed changes to
The two branches were created from different commits in the project's history

What do the conflict markers in the file mean?

They separate your side from the incoming side, with a divider between them
They mark which version Git has decided is correct for you to keep
They are Git's internal syntax and will be removed automatically on commit
They indicate the lines that were successfully merged before the conflict arose

Which two commands finish a conflict resolution?

git add on each file you resolved, then git commit to finish
git merge --continue, then git push to publish the resolution
git restore on the conflicted file, then git merge a second time
git status to confirm, then git merge --abort to close it cleanly

The conflict looks worse than expected and you want out. What do you run?

git merge --abort, which returns everything to before the merge
git revert, which undoes the merge by adding an opposite commit
git restore ., which discards the markers and completes the merge cleanly
Nothing — once a merge has started it must be resolved before anything else

You got correct