Resolve a merge conflict

Everyone hates merge conflicts before they've done a few. Then they realise conflicts are just a mechanical process: Git tells you exactly where the ambiguity is, you decide what the right answer looks like, and you finish the merge. There's nothing magical about it.

This lesson walks through one from start to finish.

When conflicts happen

Git can auto-merge when the two branches touched different files, or different parts of the same file. It gives up and asks for help only when both branches modified the same line in different ways. Then it can't decide which version wins, so it pauses the merge and hands the file to you with markers showing both versions.

What a conflict looks like

Start a merge as usual:

git merge feature

If there's a conflict, Git stops and prints:

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

Now open the conflicted file. Git has rewritten it to include both versions, separated by markers:

<<<<<<< HEAD
main version
=======
feature version
>>>>>>> feature

Reading the markers:

• <<<<<<< HEAD starts the version from HEAD (the branch you're merging into).
• ======= is the separator between the two versions.
• >>>>>>> feature ends the version from the branch being merged in.

Both versions are literally in your file. Your job is to edit the file so it says what you actually want, and delete the markers.

Resolving the conflict

You have three options for any conflicted section:

1. Keep HEAD's version. Delete the marker lines and the feature version.
2. Keep the incoming version. Delete the marker lines and the HEAD version.
3. Write a new version. Delete everything and put in whatever the combined intent is.

There's no right choice in general. It depends on what the two branches were trying to do. Read both sides, decide, edit.

For this lesson, the answer is a single line: merged note. So you'd rewrite note.txt to contain exactly that:

echo "merged note" > note.txt

Marking it resolved and completing the merge

Once the file looks right (no markers, correct content), tell Git you've resolved it:

git add note.txt

Then commit the merge:

git commit -m "Merge feature into main"

That's the end of the merge. main now sits at a merge commit with two parents, exactly like a normal diverged merge, except this one required a human decision along the way.

Escape hatch: abort the merge

If a conflict is too gnarly and you want to back out and try again later:

git merge --abort

Puts everything back the way it was before you ran git merge. No commits made, no files changed. Safe to use as many times as you need while you think about the right approach.

What to watch for

• Don't commit with markers still in the file. Git will let you. Your build will not.
• git status is your dashboard during a conflict. It lists which files are still unmerged, what state each one is in, and what commands to run next. Look at it often.
• Conflicts feel scary the first few times. They're routine after a week of practice. Nothing you do here is irreversible until you commit, and even then git reflog can help.

Both main and feature have changed the same line of note.txt to different things. When you try to merge, git can't decide which version to keep — it stops and asks you. This lesson is about completing that flow. From main, run git merge feature. Git will report a conflict in note.txt. Replace the file's contents with the single line merged note, stage it, then commit the merge with the message Merge feature into main. After this, main should be at the merge commit and the working tree should be clean.