Resolving Merge Conflicts

A merge conflict happens when two branches change the exact same lines of the exact same file in different ways, and Git genuinely cannot guess which version you want. This is normal, expected, and nothing to panic about — every developer runs into conflicts regularly.

What a conflict looks like

<<<<<<< HEADnconst greeting = "Hello, Tutoline!";n=======nconst greeting = "Welcome to Tutoline!";n>>>>>>> feature-greeting

Git marks the conflicting section directly inside the file. Everything between <<<<<<< HEAD and ======= is your current branch’s version; everything between ======= and >>>>>>> feature-greeting is the incoming branch’s version.

Resolving it

Open the file, decide which version to keep (or write a combined version that takes the best of both), and delete the conflict markers entirely — the <<<<<<<, =======, and >>>>>>> lines are not valid code and must not remain in the final file.

git add index.js       # mark the conflict as resolvedngit commit             # completes the merge

A calmer approach to conflicts

Conflicts feel alarming the first few times, mostly because the affected file temporarily looks broken. In reality, nothing is lost — both versions are sitting right there in the file for you to compare, and Git will not let you accidentally commit the raw conflict markers without at least touching the file first. Take it slowly, read both sides, and resolve one conflict at a time if a merge produces several.

Aborting a merge

git merge --abort

If a merge goes sideways and you would rather start over, this cleanly cancels the merge and returns your branch to exactly how it was beforehand — a genuine safety net worth remembering.