Automatic merge failed; fix conflicts
What Automatic merge failed actually means, how to read git's conflict markers, and the safe steps to resolve, commit, or abort the merge.
Last updated
Auto-merging src/app.js CONFLICT (content): Merge conflict in src/app.js Automatic merge failed; fix conflicts and then commit the result.
What it means: Git merged everything it safely could and found lines in the same file changed differently on both branches, so it's leaving the decision to you instead of guessing.
Likely causes
Most probable first — with how to confirm.
- 1.Two branches edited the same lines of the same file for different reasons, a common overlap during parallel feature work — open the file and look for the `<<<<<<<` / `=======` / `>>>>>>>` markers git inserted.
- 2.One branch deleted a file or block that the other branch modified — git flags this as a conflict too, not just line-level text clashes.
- 3.You're merging a long-diverged branch (rebased history vs. the original), so git sees the same logical change expressed as two different diffs.
Fixes
Safest first; destructive ones are called out.
- →Open each conflicted file, resolve the markers by choosing or combining the right content, delete the `<<<<<<<` / `=======` / `>>>>>>>` lines, then `git add <file>` and `git commit` to finish the merge.
- →Run `git status` to see the full list of conflicted files — don't assume it's only the one file git printed first.
- →For a conflict where one side should win entirely, `git checkout --ours <file>` or `--theirs <file>` picks that side wholesale — verify that's actually intended first, since it discards the other side's changes to that file.
- →If the merge is a mess, `git merge --abort` cleanly returns you to the pre-merge state — but only before you commit the resolution.
Part by part
- Auto-merging
- git attempted to combine the two versions automatically. Seeing this line means it tried before giving up, so most of the file probably merged cleanly.
- CONFLICT (content)
- The conflict type. Content means both sides edited the same region; other types include add/add and modify/delete, each needing a different resolution.
- Merge conflict in
- Followed by the file. Every conflicted file gets its own line, so the count of these tells you the size of the job ahead.
Common mistakes
git merge --abortA perfectly good escape when you started the merge by accident, and avoidance when you did mean it. Aborting repeatedly leaves the branches further apart, which makes the eventual conflict larger.
git checkout --theirs . && git add .Takes their version of every conflicted file wholesale, discarding your changes without reading them. It resolves the conflict and can silently revert work someone spent a day on.
Deleting the conflict markers and committingRemoving the markers makes the file parse again without deciding what the code should do, so you can end up with both versions of a change, or neither. Read the region, then write the correct result.
Questions
What do the conflict markers mean?
Between the opening marker and the divider is your version; between the divider and the closing marker is theirs. The label after the closing marker names the incoming branch or commit, which is often the only clue to which is which.
How do I see the common ancestor as well?
Set merge.conflictStyle to diff3 or zdiff3, and git includes the original alongside both sides. Seeing what the code was before either change usually makes the right resolution obvious.
How do I know I resolved everything?
git diff --check finds leftover conflict markers, and git status lists files still marked unmerged. Grepping for the marker characters is a useful last pass before committing.
How do I avoid these?
Smaller, shorter-lived branches, and merging or rebasing from the main branch regularly. Conflicts scale with how long two lines of work stay apart, not with how much either one changed.