When Git Refuses to Choose

Git merges most things without asking. Two people editing different files, different functions, or even different parts of the same function merge silently and correctly.

A conflict happens in one narrow situation: both sides changed the same lines since the merge base, and Git has no basis for preferring one. Rather than pick, it stops and hands the decision to you.

Auto-merging src/config.tsCONFLICT (content): Merge conflict in src/config.tsAutomatic merge failed; fix conflicts and then commit the result.

Notice the first line. Files that merged cleanly are still merged — the merge is partly done. You are in a paused merge, and git status will now tell you exactly what is left.

You have unmerged paths.  (fix conflicts and run "git commit")  (use "git merge --abort" to abort the merge) Changes to be committed:        modified:   src/routes.ts Unmerged paths:  (use "git add <file>..." to mark resolution)        both modified:   src/config.ts

This is the part that startles people. Git does not show you conflicts in a special interface — it writes them into the file on disk. Open it in any editor and the markers are really there, as text.

export function pageSize() {<<<<<<< HEAD  return 25;=======  return 50;>>>>>>> feature/bigger-pages}

Git does not check your answer. It checks only that you claimed to have one, and you make that claim with git add.

1. 1

   Open every file git status lists as unmerged

   There may be several, and each may have several conflicted regions. Work through them one at a time.

2. 2

   Edit the file until it is the code you want

   Delete all three markers. Keep one side, the other, both, or write something new — whatever is actually correct.

3. 3

   git add the file

   This is how you tell Git the conflict is resolved. Nothing is verified; adding IS the claim.

4. 4

   Run the tests before committing

   A resolved merge is new code that has never existed anywhere. It compiled on both branches and may not compile now.

5. 5

   git commit

   With no -m, Git offers a pre-written merge message listing the conflicted files. Accepting it is fine.

If you know one side is simply correct — a lockfile, a generated file, something you know was regenerated — you can say so without editing:

$ git checkout --ours package-lock.json     # the branch you are standing on$ git checkout --theirs package-lock.json   # the branch being merged in$ git add package-lock.json

Nothing about a conflicted merge is permanent until you commit. If the conflict turns out to be larger than you thought, or you started the merge in the wrong direction, or you just want to look at something first — back out completely.

$ git merge --abort         # a conflicted merge$ git rebase --abort        # a conflicted rebase$ git cherry-pick --abort   # a conflicted cherry-pick

Every one of these restores the state from immediately before the command. No commits are lost, no edits made before the merge are lost, and there is no cleanup to do.

Knowing that is what makes conflicts stop being frightening. The worst realistic outcome of attempting a merge is that you type six more words and are exactly where you started.

Conflicts scale with how long a branch has been away and how much of the file it touches. Both of those are things you control.