Resolving a merge conflict like it's not a crisis

A merge conflict just means Git found two changes to the same lines and can't guess which one you want — it's not a sign anything is broken, and it isn't rare. Treat it as a normal, expected step, not an emergency.

What you'll actually see

When a merge or rebase hits a conflict, Git pauses and marks the conflicting file with markers:

<<<<<<< HEAD
your current version of this line
=======
the incoming version of this line
>>>>>>> feature-x

git status will list every file still in conflict — work through them one at a time.

Resolving one, step by step

1. Open the file. Decide what the final content should be — that might be "keep mine," "keep theirs," or (very commonly) a combination of both, hand-written.
2. Delete the <<<<<<<, =======, and >>>>>>> marker lines entirely — they're not valid code/content, just Git's way of showing you both options in one place.
3. Stage the resolved file: git add <file>. This tells Git "this conflict is resolved."
4. Once every conflicted file is staged, continue whatever operation you were in the middle of:
   • mid-merge: git commit (Git pre-fills a merge commit message for you)
   • mid-rebase: git rebase --continue

If you get stuck

You can always back out entirely and try again with a clear head:

git merge --abort      # mid-merge
git rebase --abort     # mid-rebase

Both return you exactly to where you were before the operation started — nothing is lost.

The checkpoint for this lesson

Deliberately create a conflict: on your practice repository, edit the same line of the same file on two different branches, then merge one into the other. Resolve it by hand using the steps above, rather than accepting an editor's auto-resolve — doing it manually once is what makes the next real conflict feel routine instead of scary.