Resolving Merge Conflicts

Merge Conflicts

Scenario: You and a teammate both edited line 10 of the same file on different branches. Git can automatically combine changes to different lines, but it can't guess whose version of the same line should win - so it stops and asks you. This is a merge conflict, and it's a completely normal, everyday part of using Git as a team - not a sign anything is broken.

When it happens, Git pauses the merge partway through and marks the exact clash directly inside the file, so you can see both versions side by side:

<<<<<<< HEAD
color = "blue";        // your version (current branch)
=======
color = "green";       // their version (branch being merged)
>>>>>>> feature-theme

Read this as: everything between <<<<<<< HEAD and ======= is what's already on your current branch; everything between ======= and >>>>>>> feature-theme is what the incoming branch wants instead. Nothing is lost - you're just being shown both options.

To resolve:

Open the file, decide which version (or what combination) is correct, and delete the <<<<<<<, =======, >>>>>>> marker lines entirely - they are not code, and leaving them in by mistake is the single most common conflict-resolution error.
git add <file> to tell Git this file's conflict is resolved.
git commit to finish the merge (Git pre-fills a merge commit message for you).

Command	Helps with
`git status`	Lists which files are still conflicted
`git merge --abort`	Bail out entirely, back to exactly the pre-merge state
`git diff`	See the conflicting regions again

Tip: Panicking mid-conflict? git merge --abort rewinds everything to before the merge started, as if you'd never run git merge at all. No harm done - fix whatever you need to, then try again calmly.

Warning: The classic beginner mistake: resolving the conflict by eye but forgetting to delete the <<<<<<</=======/>>>>>>> marker lines before committing. The file now contains all of that literal text as part of your code - which usually breaks the build loudly, but in a data file or config might silently ship broken. Always re-open and re-read the file (or git diff --staged) after resolving, before you commit.