Merging & Resolving Merge Conflicts

In one line

Merging brings two branches' histories together into one — and a conflict is simply Git honestly telling you it found two changes to the exact same lines it can't safely combine on its own.

0/4 · 0%

Think of it like this

Two people editing the same shared document, one on paper and one on a photocopy, and then trying to combine both sets of edits back into one final copy — most edits (different paragraphs) combine automatically and obviously; a conflict only happens when both people changed the EXACT SAME sentence differently, and a human has to decide which version (or what combination) is correct.

Key ideas

01
git merge <branch> combines the named branch's history into your CURRENT branch, creating a MERGE COMMIT (Phase 0.5's two-parent commit) that represents the point where the two histories join. If the two branches changed entirely different parts of the codebase, Git merges them automatically with no conflict at all — this is the common case, not the exception.
02
A CONFLICT happens specifically when both branches changed the SAME lines of the SAME file in different ways — Git can't know which version is correct, so it pauses the merge and marks the file with conflict markers (<<<<<<<, =======, >>>>>>>) directly in the file's content, showing both versions side by side for you to resolve manually.
03
Resolving a conflict means editing the file to keep whichever content is actually correct (one side, the other, a combination, or something new entirely), removing ALL the conflict marker lines completely, then git adding the resolved file to mark it as done, and finally git commit to complete the merge with the resolution baked in.
04
git status during an unresolved merge clearly lists every file still in conflict under 'Unmerged paths' — genuinely useful for tracking your progress on a merge touching multiple conflicted files, since it updates as each one gets resolved and staged.
05
git merge --abort cleanly cancels an in-progress merge and returns your branch to exactly the state it was in before you started — genuinely useful when a merge turns out to have far more conflicts than expected, or you realize you merged the wrong branch, and want a clean restart rather than resolving your way out.

Code & diagrams

MergeConflictdiagram

Two branches, both changed line 3 differently — Git can't guess which is correct.

Rendering diagram…

resolving-a-conflict.shmarkdown

A genuine conflict, created on purpose, resolved start to finish.

cd ~/scratch/my-first-repo

# Set up two branches that will genuinely conflict
git switch -c branch-a main
echo "Line changed by branch-a" > conflict.txt
git add conflict.txt && git commit -m "Change on branch-a"

git switch -c branch-b main
echo "Line changed by branch-b" > conflict.txt
git add conflict.txt && git commit -m "Change on branch-b"

# Attempt the merge — this WILL conflict
git switch branch-a
git merge branch-b
# CONFLICT (content): Merge conflict in conflict.txt

git status
# shows conflict.txt under "Unmerged paths"

cat conflict.txt
# <<<<<<< HEAD
# Line changed by branch-a
# =======
# Line changed by branch-b
# >>>>>>> branch-b

# Resolve by hand — edit the file to keep the correct final content,
# removing every conflict marker line completely, e.g.:
echo "Line changed by branch-a" > conflict.txt

git add conflict.txt
git commit -m "Merge branch-b into branch-a, keeping branch-a's version"
git status
# clean — the merge is complete

# If it had gone badly wrong instead:
# git merge --abort

Explain it without notes

Why does Git sometimes merge two branches with zero conflicts at all, even though both branches changed real code?

You're mid-merge with conflict markers in a file. What are the exact steps to finish resolving it correctly?

Practice

Deliberately create two branches that edit the same line of the same file differently, merge them, and walk through resolving the conflict by hand, start to finish.

Start a merge that you know will conflict, then use git merge --abort instead of resolving it, and confirm your branch is back exactly where it started.

Trade-offs

↔
Merging preserves the exact, real branching history (you can see precisely where and when two lines of work came together) at the cost of a more complex-looking graph over time, with merge commits interspersed throughout — this is exactly the trade-off Topic 2.3 examines directly against rebasing, which produces a cleaner-looking linear history at the cost of that branching record.

Done when you can

I understand why some merges succeed automatically while others conflict.
I can resolve a real merge conflict by editing the file and completing the merge.
I know git merge --abort exists and can cleanly back out of a merge gone wrong.