Resolving a Merge Conflict Without Panicking — What Git Is Actually Showing You
A merge conflict isn't Git failing -- it's Git correctly refusing to guess between two changes it can't safely combine on its own, and handing the decision back to you.
The existing branching-strategies piece in this category mentions merge conflicts in passing without walking through one. This one closes that loop: what a conflict actually is, what Git is showing you when one happens, and how to work through it methodically instead of guessing.
A merge conflict happens when two branches have each changed the same lines of the same file (or one branch edited a line the other deleted) since the point where they last shared a common history. Git can automatically merge changes to different parts of a file without any trouble at all -- a conflict only happens specifically where it genuinely can't tell which of two competing changes should win, and rather than silently guessing, it stops and asks.
Opening a conflicted file shows a specific, structured markup Git inserts directly into it: <<<<<<< HEAD marks the start of your current branch's version of the conflicting lines, a row of ======= separates it from the other side, and >>>>>>> followed by a branch name or commit marks the end of that other branch's version of the same lines. Everything between those markers is exactly, and only, the specific lines Git couldn't reconcile on its own -- the rest of the file is untouched and already merged correctly.
Resolving the conflict means editing that section down to what the file should actually contain -- one side's version, the other's, some combination of both, or something new entirely -- and deleting every one of the marker lines themselves in the process, since they're not valid code or content, just Git's own scaffolding. Once every conflicted section in a file is resolved and the markers are gone, staging the file (git add) marks it as resolved, and running git commit (for a merge) or git rebase --continue (for a rebase) finishes the operation.
Worth knowing before diving in: git merge --abort (or git rebase --abort mid-rebase) safely backs all the way out of a confusing conflict resolution and returns to exactly the state before the merge started, with no changes lost -- a genuinely useful safety valve when a conflict resolution starts to feel like it's making things worse rather than better, letting you step back, re-read both sides' actual changes, and try again from a clean state.