Merge Conflicts Handling

A merge conflict is not an error. It is Git admitting there is exactly one decision it is not qualified to make, and handing it to you. This module makes that handover routine.

Why This Module Matters

The first conflict a person hits is genuinely frightening. The terminal fills with capital letters, files sprout rows of angle brackets, and it feels like something has been broken irreversibly. Nothing has. The repository is intact, both versions of every line are safely present, and one command puts everything back exactly as it was.

What conflicts actually mean is narrow and specific: two branches changed the same lines of the same file, and Git will not guess which one wins. Different files? No conflict. Different parts of the same file? Usually no conflict. Same lines? Your call.

Once you can read the three markers on sight and follow one fixed sequence — inspect, decide, add, commit — conflicts stop being a crisis and become a five-minute chore. That is the whole point of this module.

What You'll Learn

• The precise condition that produces a conflict, and the many situations that don't
• How to read <<<<<<< HEAD, ======= and >>>>>>> branch-name — and which side is which
• Why git status is the authoritative list of what still needs resolving
• The fixed algorithm: inspect → edit → git add → git commit
• Why git add on a conflicted file means "I have resolved this", not "stage my edit"
• How git merge --abort returns you to the exact state before the merge started

Pro Tip

Resolving a conflict means the file must contain no <<<<<<<, ======= or >>>>>>> lines at all. Search for them before you stage. A committed conflict marker is a genuine production bug, and it has shipped more than once.