Resolving Merge Conflicts

By the end of this lesson you'll be able to read Git's conflict markers, resolve a clash by hand, finish the merge with git add and git commit , bail out safely with git merge --abort , and structure your work so conflicts rarely happen at all.

Learn Resolving Merge Conflicts in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

A merge conflict is like two people editing the same sentence of a shared document at the same time. When their edits come together, the document can't show both, so it asks: "Alice wrote blue but Bob wrote green — which should I keep?" Git is exactly that careful editor. It happily combines edits to different sentences on its own, but when two edits land on the same line it stops and lets you , the human, make the final call. A conflict isn't an error or a bug — it's Git refusing to silently throw away someone's work.

1️⃣ Why Conflicts Happen

Git is very good at merging changes automatically. A conflict happens only when two branches modify the exact same lines of the same file . Different files, or different lines of the same file? Git merges them for you with no fuss. Read this worked example, then run a merge and watch Git stop.

2️⃣ Reading the Conflict Markers

When a conflict occurs, Git edits the file and wraps the clashing lines in three markers. Everything between <<<<<<< HEAD and ======= is your version (the branch you're on, called HEAD ); everything between ======= and >>>>>>> is theirs (the branch coming in). Lines outside the markers merged cleanly.

3️⃣ Resolving by Hand

Resolving means making a decision and cleaning up. You edit the file to the version you actually want — keep yours, keep theirs, combine both, or write something new — and then delete all three markers . The conflict is "resolved" the moment no markers remain. Here's the same file from above, finished.

Your turn. Below is a conflict in greeting.txt . You've decided the page should greet returning visitors. Replace the ___ with the one line that should remain — and remember, no markers belong in the finished file.

4️⃣ Finishing the Merge

Editing the file isn't quite the end. You have to tell Git the conflict is fixed by staging the file with git add , then complete the merge with git commit . Use git status at any point to see which files are still "both modified".

Now you finish a merge. You've already edited config.json and removed every marker — only the two final commands remain. Fill in the blanks.

5️⃣ The Escape Hatch: git merge --abort

Sometimes you start a merge and realise it's the wrong branch, or the conflicts are bigger than expected. Don't panic and start deleting markers at random. One command rewinds you to exactly how things were before the merge — like it never happened.

6️⃣ Resolution Tools

You never have to manage markers in a bare text editor. VS Code recognises conflicts and shows clickable Accept Current Change , Accept Incoming Change , and Accept Both Changes buttons right above each clash, plus a side-by-side comparison. Most editors and IDEs (JetBrains, Sublime) have the same. Git also ships git mergetool , which opens a dedicated three-way merge view. Whatever tool you use, the end state is identical: the right content, and no markers left behind.

7️⃣ Preventing Conflicts

The best conflict is one that never happens. Merge from main often so your branch doesn't drift, keep branches small and focused, talk to your team so two people aren't rewriting the same file, and use .gitignore so generated files never collide.

📋 Quick Reference

No blanks this time — just a brief and an outline. Reproduce a real conflict in your own terminal and take it all the way to a clean merge. This is the exact loop you'll run on real projects.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary