Resolving Merge Conflicts

A screen full of <<<<<<< symbols is the moment most beginners close the terminal. It should not: this sixth chapter of the Git and GitHub for Beginners series shows that a conflict is Git politely refusing to guess, and that resolving one is a short routine you can walk through calmly every single time.

Why conflicts happen

Git merges automatically when two branches touch different files — or even different regions of the same file. It stops only when both sides changed the same lines and no algorithm can decide which version you actually want. Picture a page where main updates the opening hours while a feature branch rewrites them for a holiday schedule: Git will not silently throw away either version. Instead it pauses, marks the file, and asks you to make a human decision. Nothing is broken, nothing is lost, and your repository is exactly as it was before the merge attempt — conflicts are a normal part of teamwork, not an error state.

Anatomy of a conflict marker

When Git halts, it writes the disputed region into your file wrapped in three marker lines:

<h2>Opening hours</h2>
<<<<<<< HEAD
<p>Open 8 am to 8 pm daily.</p>
=======
<p>Open 9 am to 9 pm, closed Mondays.</p>
>>>>>>> feature-online-orders

• <<<<<<< HEAD opens your version — the branch you had checked out (also called ours).
• ======= separates the two sides.
• >>>>>>> feature-online-orders opens the incoming version (theirs), labelled with the other branch's name.

Your entire job is to rewrite that region into the result you want — keep one side, keep the other, or write a third — and delete all three marker lines. The markers must never survive into the committed file; leaving them in is the one true conflict-resolution bug.

The four-step fix

1. Survey — run git status. It lists every file under “Unmerged paths”. Work through them one by one.
2. Edit — open each file, resolve each marked region, save.
3. Mark resolved — git add <file>. Here add means “this conflict is settled”, not “stage new work”.
4. Commit the merge — git commit finishes the merge with a default message you can keep as-is.

Repeat steps 2 and 3 for every file Git listed. When status reports “all conflicts fixed but you are still merging”, one final commit closes the process.

Tools that help (and the escape hatch)

• Take a whole side — git checkout --ours <file> or git checkout --theirs <file> keeps one version wholesale. Beware the naming: during a merge, ours is the branch you were on when you started it, which is not always the branch you expect.
• Visual merging — git mergetool opens a three-pane editor if you prefer buttons to marker surgery.
• Bail out safely — git merge --abort restores the exact pre-merge state, files included. Using it is not failure; it is a reset button.
• See what arrived — git log --oneline --graph -6 shows how the two lines of history connect before you choose.

Keep this quick reference handy — it covers every move a conflict can demand:

Preventing conflicts before they happen

Conflicts grow with the distance between branches, so prevention is mostly discipline: pull the latest main before starting work, merge or rebase your branch at least daily, keep each branch to one focused change, and tell teammates which files you are touching. Two people rewriting the same function for a week guarantees a conflict; two-day branches rarely meet one.

git merge feature-online-orders

Expected output:

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

git status

Expected output:

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   index.html

no changes added to commit

git add index.html
git commit -m "Merge branch 'feature-online-orders' with new opening hours"

Expected output:

[main d4e5f6a] Merge branch 'feature-online-orders' with new opening hours

Common mistakes

• Committing with the markers still in the file — the merge “succeeds” and ships broken markup; search for <<<<< before every conflict commit.
• Forgetting to git add the resolved file — Git still considers the path unmerged and refuses to finish the commit.
• Panicking and running merge --abort after already editing — abort discards your resolutions too; resolve properly or abort before you start, not halfway through.
• Assuming a conflict means someone's work is deleted — both sides stay in history; you are only choosing what the next snapshot contains.
• Resolving alone in silence — if the “right” version is a product decision, ask the teammate whose code you are merging.

Practice checklist

1. Create two branches, edit the same lines of one file on each, and merge to force a conflict on purpose.
2. Read the markers aloud: identify ours, theirs, and the separating line.
3. Resolve the file by hand, removing every marker, then run git status before staging.
4. Stage the file, commit, and confirm with git log --oneline --graph that both branches are joined.
5. Repeat the exercise and finish it with git merge --abort to prove the reset button works.

What's next?

Local merging is now in your toolkit — but your teammates cannot see your work until it leaves your machine. Continue to Working with Remotes and GitHub to connect your repository to the world.