This error occurs when you attempt to start a new merge while Git is already in a merge state with unresolved conflicts. You must first resolve the existing conflicts from the previous merge, stage the changes, and complete or abort that merge before starting a new one.
The "error: Merging is not possible because you have unmerged files" message indicates that Git is already in the middle of a merge operation that has encountered conflicts. When you tried to run another merge command, Git refused because the previous merge hasn't been completed. When a merge conflict occurs, Git enters a special "merging" state. In this state, Git has combined as much as it could automatically, but some files contain conflicting changes that require manual resolution. These files are marked as "unmerged" in the working directory. What Git is really telling you: "You are already in a merge state and need to resolve the conflicts there first!" Until you either: 1. Resolve all conflicts and complete the merge with a commit 2. Abort the current merge entirely You cannot start any new merge operations. This is a safety feature to prevent you from getting into an even more confused state.
First, understand what state your repository is in:
git statusExample output when in merge conflict state:
On branch main
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/app.js
both modified: src/config.json
no changes added to commit (use "git add" and/or "git commit -a")This tells you which files have conflicts that need resolution.
Use git diff to see what changes are in conflict:
# See all conflicts
git diff
# See conflicts in a specific file
git diff src/app.jsYou can also view which files are conflicted:
# List only unmerged files
git diff --name-only --diff-filter=UThis helps you understand what changes need to be reconciled before proceeding.
Open each conflicted file and look for conflict markers:
<<<<<<< HEAD
// Your current branch's version
const port = 3000;
=======
// The incoming branch's version
const port = 8080;
>>>>>>> feature-branchTo resolve:
1. Decide which version to keep (or combine both)
2. Remove all conflict markers (<<<<<<<, =======, >>>>>>>)
3. Save the file
Example resolution (keeping port 8080):
const port = 8080;Using VS Code or your editor:
Most modern editors detect conflict markers and provide clickable options:
- "Accept Current Change" (keep HEAD version)
- "Accept Incoming Change" (keep the other branch)
- "Accept Both Changes" (combine both)
- "Compare Changes" (see side-by-side diff)
If you want to accept one side's changes completely:
Accept your current branch's version (discard incoming):
git checkout --ours path/to/file.jsAccept the incoming branch's version (discard yours):
git checkout --theirs path/to/file.jsFor all conflicted files:
# Accept all of ours
git checkout --ours .
# Accept all of theirs
git checkout --theirs .After using checkout, you still need to stage the files with git add.
After resolving conflicts, mark the files as resolved by staging them:
# Stage a specific resolved file
git add src/app.js
# Stage all resolved files
git add .Verify all conflicts are resolved:
git statusYou should now see:
On branch main
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: src/app.js
modified: src/config.jsonOnce all conflicts are resolved and staged, complete the merge:
git commitGit will open your default editor with a pre-filled merge commit message:
Merge branch 'feature-branch' into main
# Conflicts:
# src/app.js
# src/config.jsonSave and close the editor to complete the merge.
Or use a custom message:
git commit -m "Merge feature-branch: resolve config conflicts"After this, you're out of the merge state and can proceed with new operations.
If you want to abandon the merge and go back to the state before it started:
git merge --abortThis will:
- Restore your working directory to the state before the merge
- Clear the merge state
- Discard any conflict resolutions you made
Verify the abort worked:
git statusYou should see a clean working directory without merge conflicts.
Note: If you have uncommitted changes before the merge, --abort will try to restore them, but this may not always be possible. It's best to commit or stash changes before merging.
For complex conflicts, use a visual merge tool:
git mergetoolThis launches your configured merge tool (vimdiff, meld, kdiff3, VS Code, etc.).
Configure a merge tool:
# Set VS Code as the merge tool
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'
# Set meld as the merge tool
git config --global merge.tool meld
# List available tools
git mergetool --tool-helpAfter using mergetool:
Git automatically stages resolved files, but creates .orig backup files. Clean them up:
# Remove .orig files
find . -name "*.orig" -delete
# Or configure Git to not create them
git config --global mergetool.keepBackup falseIf you made a mess of resolving conflicts and want to start fresh:
# Re-checkout the file with conflict markers
git checkout --conflict=merge path/to/file.jsThis restores the original conflict markers so you can try resolving again.
Or use git restore (Git 2.23+):
# Restore to conflicted state
git restore --conflict=merge path/to/file.js
# Unstage a file without losing changes
git restore --staged path/to/file.jsThis is useful when you accidentally removed the wrong code during conflict resolution.
Prevention: Clean working directory before merging
Always ensure your working directory is clean before starting a merge:
# Check status first
git status
# Stash uncommitted changes if needed
git stash
# Do the merge
git merge feature-branch
# Restore stashed changes
git stash popUnderstanding Merge vs Rebase conflicts
This error can also occur during a rebase operation. The resolution is similar but uses different commands:
# For rebase conflicts
git rebase --abort # Instead of git merge --abort
git rebase --continue # After resolving, instead of git commitRerere: Reuse Recorded Resolution
If you frequently encounter the same conflicts, enable rerere to remember your resolutions:
git config --global rerere.enabled trueGit will record how you resolved conflicts and automatically apply the same resolution next time.
Merge strategies for avoiding conflicts
You can use different merge strategies to handle conflicts:
# Always prefer our changes (use with caution)
git merge -X ours feature-branch
# Always prefer their changes
git merge -X theirs feature-branchChecking merge base
To understand what's being merged and where conflicts might arise:
# Find the common ancestor
git merge-base main feature-branch
# See what changed on each side since the fork point
git log $(git merge-base main feature-branch)..main
git log $(git merge-base main feature-branch)..feature-branchPull vs Fetch + Merge
git pull is actually git fetch + git merge. For more control:
# Fetch changes first (safe, no merge)
git fetch origin
# Review incoming changes
git log HEAD..origin/main
# Then merge when ready
git merge origin/mainThis gives you a chance to review changes before potentially creating conflicts.
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git
fatal: unable to access: no_proxy configuration not working
How to fix 'no_proxy configuration not working' in Git
fatal: unable to read tree object in treeless clone
How to fix 'unable to read tree object in treeless clone' in Git