A merge conflict is Git asking for a decision. Two branches changed the same part of the same file, or one deleted a file the other edited, and Git cannot tell which version is correct. It stops the merge or rebase and marks the spots that need a person.
In the file, a conflict looks like three markers. The lines between <<<<<<< and ======= are one side, the lines between ======= and >>>>>>> are the other. You edit the file until it contains what should actually be there, remove the markers, then git add the file and continue. git status lists every file still marked “both modified.” If it goes badly, git merge --abort or git rebase --abort puts you back where you started.
On GitHub a pull request with conflicts shows “This branch has conflicts that must be resolved,” and simple text conflicts can be fixed in the web editor. GitLab has a similar resolver. Anything bigger is usually easier in your editor, most of which show the two sides next to each other with buttons for each block.
Prevention is mostly habit. Keep branches short-lived. Pull the target branch in often so conflicts arrive small. Agree on formatting with a formatter, so whitespace and import order stop colliding. If the same conflict keeps coming back during a long rebase, git config rerere.enabled true tells Git to remember how you resolved it.
A conflict is not an error in anyone’s work. It is two correct changes that need an editor.
The piece reads “MERGE CONFLICT.” and nothing else. Most people who wear it can name the file.
In the wild
Heads up, your branch and mine both touched routes.ts. I’ll rebase on yours and resolve the conflict.
