Resolving Merge Conflicts, Calmly

Few things spook a Git newcomer like the word conflict. It sounds like something broke, like you've done damage. You haven't. A merge conflict is one of the most benign things Git does — it's Git being careful, pausing to ask you a question it can't safely answer alone. This chapter turns that moment of panic into a routine you can handle without your pulse rising.

Why conflicts happen (and when they don't)

Recall the three-way merge from the branching chapter: Git compares two branches against their common ancestor and combines the changes. Most of the time this is automatic. If your branch changed the header and the other branch changed the footer, those are independent edits to different lines — Git keeps both without asking. The overwhelming majority of merges have no conflict at all.

A conflict happens in exactly one situation: both branches changed the same lines of the same file. Now Git is stuck. It can see that you rewrote line 12 one way and someone else rewrote line 12 another way, and it has no basis for deciding which is correct — that's a judgment call about meaning, and Git doesn't understand your code's meaning. So rather than guess and risk silently destroying someone's work, it stops and hands the decision to you.

What Git does when it hits one

When a merge (or a pull, which is a merge) conflicts, Git does three things. It pauses the merge partway through. It marks the conflicted files so you can find them. And inside each conflicted file, it inserts conflict markers showing you both versions of the disputed lines, sitting right next to each other. Every change that didn't conflict is already merged cleanly — only the genuinely contested lines are left for you.

Reading the conflict markers

Open a conflicted file and you'll see something like this:

<<<<<<< HEAD
The price is displayed in US dollars.
=======
The price is shown in the user's local currency.
>>>>>>> feature/localized-pricing

It looks alarming; it's actually simple. There are three parts:

• Everything between <<<<<<< HEAD and ======= is your current version — the branch you were on when you started the merge.
• Everything between ======= and >>>>>>> is the incoming version — from the branch being merged in. The name after >>>>>>> tells you which branch it came from.
• The <<<, ===, >>> lines are just markers. They are not code, not part of your file — they're Git's scaffolding, and they must all be gone by the time you're done.

So Git is laying both proposals side by side: "you wanted this, they wanted that — what should the final line actually say?"

Resolving one, step by step

Resolving a conflict is nothing more than editing the file until those lines say what's correct, then telling Git you're done. The steps:

1. Open each conflicted file and find the marked sections.
2. Decide the right answer for those lines. Sometimes you keep your version, sometimes theirs, sometimes you combine both, and sometimes you rewrite the lines entirely into something new. You are not forced to pick a side — you're writing the final truth.
3. Delete all three markers (<<<<<<<, =======, >>>>>>>) so only the real content remains.
4. Stage the file — using the staging area from earlier — which is how you signal to Git "this one's resolved."
5. When every conflicted file is staged, complete the merge, which records the merge commit and ends the pause.

You can always back out

Here's the reassurance that removes the last of the fear: a conflicted merge is fully reversible. If you look at the conflict and decide you're not ready — you want to talk to the other author, or you started the merge by mistake — you can abort the merge, and Git puts everything back exactly as it was before you started. No commits, no damage, no trace. There is no point of no return in the middle of a merge. That safety net means you can always start a merge just to see whether it conflicts, and bail out with zero cost if it does.

The routine, not the emergency

Strip away the scary reputation and a merge conflict is a small, well-defined task: Git found two edits to the same lines, showed you both, and asked which should win. You read the markers, write the correct final version, remove the markers, stage the file, and finish — or you abort and walk away. On any active team, conflicts are a normal and frequent part of working together, not a sign anything went wrong. Handle a few and it becomes muscle memory. Next, we look at a tool that can reduce how often you deal with tangled history in the first place — and stirs up strong opinions in the process: rebase, and how it differs from merge.