How to Resolve Git Merge Conflicts: Fix “Automatic Merge Failed”

Git how to resolve merge conflicts: fix “automatic merge failed fix conflicts and then commit the result” and “this branch has conflicts that must be resolved” in Azure DevOps pull requests.

What Is a Merge Conflict and Why Does It Happen?

A merge conflict occurs when Git tries to combine two branches but cannot automatically decide which version of the code to keep. Git is remarkably good at merging — it can handle hundreds of files changing in parallel. But when two people edit the same lines of the same file, or when one person deletes a file that another person modified, Git stops and asks you to decide.

Understanding the three-way merge model helps: Git looks at the shared ancestor commit, your changes, and the other branch’s changes. If both sides changed the same spot, that’s a conflict.

“This branch has conflicts that must be resolved” — what it means

This message appears in GitHub, GitLab, Bitbucket, and Azure DevOps pull request interfaces. It means the target branch (usually main or develop) has received commits that conflict with commits on your feature branch. The platform is blocking the merge button to protect you from data loss.

“Automatic merge failed; fix conflicts and then commit the result” — what Git is telling you

This is the terminal message you see after running git merge or git pull when Git encounters a conflict. Here is what it looks like in full:

Git is telling you three things: which file(s) conflict, that it stopped without completing the merge, and exactly what to do next — fix the conflicts, then commit. Your working directory is now in a merging state, and Git has inserted conflict markers directly into the conflicting files to show you both sides.

How to Identify Conflict Markers in Your Code

When Git detects a conflict, it does something concrete: it edits the conflicting file and inserts conflict markers — special lines that clearly label “your side” and “their side.” You must read and remove these markers before the code can compile or run.

Understanding <<<<<<<, =======, and >>>>>>>

The three conflict markers divide a conflicted block into two halves:

• <<<<<<< HEAD — marks the start of your changes (the branch you were on when you ran merge)
• ======= — the dividing line between the two versions
• >>>>>>> branch-name — marks the end of the incoming changes (the branch you are merging in)

How to find all conflicting files

After a failed conflicts merge, you have several ways to discover which files need attention:

# Method 1 — git status (fastest)
git status

# Method 2 — list only conflicted files
git diff --name-only --diff-filter=U

# Method 3 — grep for conflict markers across all files
grep -rn "<<<<<<<" .

# Method 1 — git status (fastest)
git status

# Method 2 — list only conflicted files
git diff --name-only --diff-filter=U

# Method 3 — grep for conflict markers across all files
grep -rn "<<<<<<<" .

How to Resolve Merge Conflicts Manually

Manual resolution is the most fundamental skill — even if you use a GUI tool, you need to understand what you are choosing. The process always follows the same three steps: edit the file, stage it, commit.

Choosing one side vs. combining changes

You have three options when you look at a conflict block:

// AFTER — combined: use Alice's timeout but add Bob's comment
  timeout: 5000,  // increased for slower networks (was 3000)

// AFTER — combined: use Alice's timeout but add Bob's comment
  timeout: 5000,  // increased for slower networks (was 3000)

Marking conflicts as resolved with git add

Once you have edited a file and removed all conflict markers, you must explicitly tell Git the conflict is resolved. This is done with git add:

# Stage each resolved file individually
git add src/config.js
git add src/api/client.js

# Or stage everything at once
git add .

# Verify — no more "Unmerged paths" should appear
git status

# Stage each resolved file individually
git add src/config.js
git add src/api/client.js

# Or stage everything at once
git add .

# Verify — no more "Unmerged paths" should appear
git status

Completing the merge with git commit

Once all conflicts are staged, finalize the merge with a commit. Git will pre-populate a merge commit message for you — you can accept it or customize it:

1. Run git commit

git commit
# Git opens your editor with a pre-filled message:
# Merge branch 'feature/bob-perf-fix' into main
# ...

git commit
# Git opens your editor with a pre-filled message:
# Merge branch 'feature/bob-perf-fix' into main
# ...

2. Save and close the editor (or use -m)

# Or skip the editor entirely:
git commit --no-edit

# Or skip the editor entirely:
git commit --no-edit

3. Push the result (if working with a remote)

git push origin main

git push origin main

Best Tools to Resolve Merge Conflicts

Manual text editing works, but a visual merge tool makes conflict resolution significantly faster and less error-prone — especially for large diffs. Here are the best options depending on your workflow.

Built-in: git mergetool

Git ships with a mergetool command that launches a configured merge tool for each conflicted file. You can set your preferred tool once and use it every time:

# Set VS Code as the default merge tool globally
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd \
  'code --wait $MERGED'

# Set vimdiff (no install required)
git config --global merge.tool vimdiff

# Launch the tool on all conflicted files
git mergetool

# Set VS Code as the default merge tool globally
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd \
  'code --wait $MERGED'

# Set vimdiff (no install required)
git config --global merge.tool vimdiff

# Launch the tool on all conflicted files
git mergetool

VS Code merge editor

VS Code has a first-class merge editor with an inline 3-way diff view. When you open a conflicted file, VS Code shows “Accept Current Change”, “Accept Incoming Change”, “Accept Both Changes”, and “Compare Changes” inline — no configuration required.

# Open the conflicted file directly in VS Code
code src/config.js

# Or use VS Code as git mergetool (see above)
# The 3-way merge editor opens automatically for .git conflicts

# Open the conflicted file directly in VS Code
code src/config.js

# Or use VS Code as git mergetool (see above)
# The 3-way merge editor opens automatically for .git conflicts

IntelliJ / WebStorm

JetBrains IDEs include one of the most powerful merge editors available. The 3-pane view shows your version (left), the result (center), and the incoming version (right). You can accept individual changes with arrow buttons and edit the result pane directly.

1. VCS menu → Git → Resolve Conflicts
2. Double-click a conflicted file
3. Use << / >> arrows to accept change blocks
4. Click "Apply" when done
5. Commit via VCS → Commit (Ctrl+K)

1. VCS menu → Git → Resolve Conflicts
2. Double-click a conflicted file
3. Use << / >> arrows to accept change blocks
4. Click "Apply" when done
5. Commit via VCS → Commit (Ctrl+K)

Sublime Merge, GitKraken, and others

How to Prevent Merge Conflicts in the First Place

You cannot eliminate merge conflicts entirely — they are a natural result of parallel development. But you can dramatically reduce their frequency and severity with a few disciplined habits.

Keep branches short-lived

The longer a branch lives, the more the base branch diverges from it, and the bigger the conflict when you finally merge. Aim to merge feature branches in days, not weeks.

Pull and rebase frequently

Keeping your branch up to date with the base branch means smaller gaps and smaller conflicts. Two strategies — pick one and be consistent:

# While on your feature branch, pull in latest main
git fetch origin
git merge origin/main

# Resolve any conflicts early, while they're still small

# While on your feature branch, pull in latest main
git fetch origin
git merge origin/main

# Resolve any conflicts early, while they're still small

# Rebase your commits on top of the latest main
git fetch origin
git rebase origin/main

# If conflicts occur during rebase, resolve each commit's
# conflict one at a time, then:
git add .
git rebase --continue

# To abort the rebase and return to before:
git rebase --abort

# Rebase your commits on top of the latest main
git fetch origin
git rebase origin/main

# If conflicts occur during rebase, resolve each commit's
# conflict one at a time, then:
git add .
git rebase --continue

# To abort the rebase and return to before:
git rebase --abort

• Communicate with your team before editing shared files — a quick Slack message prevents half of all conflicts
• Split large files into smaller modules — conflicts in a 50-line file are trivial; conflicts in a 2,000-line file are painful
• Use .gitattributes to define merge strategies for generated files (e.g., lock files, compiled assets)
• Configure CI to block merges where the branch is more than N commits behind main
• Consider using git rerere (reuse recorded resolution) to auto-apply resolutions you’ve already made to identical conflicts

# Enable rerere globally — Git will remember your resolutions
git config --global rerere.enabled true

# After resolving a conflict once, Git will auto-resolve
# the identical conflict if it appears again (e.g., during rebase)

# Enable rerere globally — Git will remember your resolutions
git config --global rerere.enabled true

# After resolving a conflict once, Git will auto-resolve
# the identical conflict if it appears again (e.g., during rebase)

Frequently Asked Questions

Also read proven strategies to follow best branching git workflow.