How to Fix Git Merge Conflict: Complete Step-by-Step Guide 2026

A merge conflict happens when Git can’t automatically combine changes because two branches modified the same lines differently. It’s a normal part of collaboration — not an error, just Git asking you to decide. Here’s how to resolve conflicts confidently.

What Causes a Merge Conflict

When you merge (or rebase, or pull) and both branches changed the same part of a file differently, Git can’t decide which change to keep — so it stops and asks you. You’ll see:

$ git merge feature-branch
Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts and then commit the result.

Understanding Conflict Markers

<<<<<<< HEAD
const greeting = "Hello from main branch";
=======
const greeting = "Hi from feature branch";
>>>>>>> feature-branch

// The markers mean:
// <<<<<<< HEAD          → your current branch's version (above =======)
// =======              → divider
// >>>>>>> feature-branch → the incoming branch's version (below =======)

Step-by-Step Resolution

# 1. See which files have conflicts
git status
# Unmerged paths:
#   both modified:   app.js

# 2. Open each conflicted file and find the conflict markers

# 3. Edit the file to the desired final state - choose one version,
#    combine both, or write something new. REMOVE the markers.

# Before (with markers):
<<<<<<< HEAD
const greeting = "Hello from main branch";
=======
const greeting = "Hi from feature branch";
>>>>>>> feature-branch

# After (resolved - you decided):
const greeting = "Hi from feature branch";

# 4. Stage the resolved file
git add app.js

# 5. Complete the merge
git commit           # opens editor with a default merge message, or:
git commit -m "Merge feature-branch, resolve greeting conflict"

Resolving Multiple Conflicts

# A file (or several) may have multiple conflict sections.
# Find them all:
grep -n "<<<<<<<" app.js       # find conflict markers

# Resolve each section, then verify none remain:
grep -rn "<<<<<<<\|=======\|>>>>>>>" .
# Should return nothing when all conflicts are resolved

# Then stage all resolved files and commit
git add .
git commit

Using a Merge Tool

# Configure and use a visual merge tool (easier for complex conflicts)
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'

# Launch the tool for conflicts
git mergetool
# VS Code (or your tool) shows current/incoming/result panes for easy resolution

# VS Code also has built-in conflict resolution - it shows
# "Accept Current / Accept Incoming / Accept Both" buttons inline

Aborting a Merge

# If you want to cancel the merge and start over
git merge --abort
# Returns your branch to the state before the merge - nothing changed

# For a conflicted rebase:
git rebase --abort

# For a conflicted pull:
git merge --abort   # (a pull is a fetch + merge)

Resolving Conflicts During Rebase

# Rebase conflicts are resolved similarly, but per-commit:
git rebase main
# CONFLICT in app.js

# 1. Resolve the conflict in the file
# 2. Stage it
git add app.js
# 3. Continue the rebase (NOT commit)
git rebase --continue
# Repeat if more commits have conflicts

Preventing Conflicts

• Pull frequently: Staying current with the main branch reduces divergence and conflicts
• Make smaller, focused commits: Easier to merge than large sweeping changes
• Communicate with your team: Coordinate who’s working on what to avoid overlapping changes
• Merge/rebase often: Integrate changes regularly rather than letting branches diverge for weeks
• Keep branches short-lived: Long-running branches accumulate conflicts

Frequently Asked Questions

Q: What do the conflict markers mean?
A: <<<<<<< HEAD starts your current branch’s version, ======= divides it from the incoming version, and >>>>>>> branch-name ends the incoming version. Edit the file to your desired final state and remove all three markers, then stage and commit.

Q: How do I choose which version to keep?
A: Understand what each change does, then decide: keep yours, keep theirs, combine both, or write something new. There’s no automatic “right” answer — it depends on what the code should do. When unsure, ask the person who made the other change. Edit to the correct final state.

Q: I made a mistake resolving. How do I start over?
A: If you haven’t committed yet, run git merge --abort (or git rebase --abort) to cancel and return to the pre-merge state. Then start the merge again. If you already committed a bad resolution, you can revert or reset the merge commit.

Q: How do I know all conflicts are resolved?
A: Run git status (no unmerged paths remaining) and search for leftover markers: grep -rn "<<<<<<<" . should return nothing. Leftover conflict markers in files cause bugs, so always verify none remain before committing.

Q: Why do I keep getting the same conflict during rebase?
A: Rebase applies your commits one at a time, so a conflict can recur across multiple commits touching the same code. Resolve each, git add, and git rebase --continue. If it’s genuinely repetitive, consider git rerere (reuse recorded resolution) or merging instead of rebasing.

Conclusion

Merge conflicts are a normal part of collaboration, not errors — Git is asking you to decide when two branches changed the same code differently. The resolution process: find conflicted files with git status, open them and locate the conflict markers (<<<<<<< HEAD / ======= / >>>>>>>), edit to your desired final state removing the markers, then git add and git commit. Use a visual merge tool (VS Code) for complex conflicts, and git merge --abort to start over if needed. During rebase, resolve per-commit and use git rebase --continue. Prevent conflicts by pulling frequently, making small commits, and keeping branches short-lived. Once you understand the markers and the process, conflicts become routine — just Git asking for a decision you’re equipped to make.