Fix 'You have not concluded your merge (MERGE_HEAD exists)'
Git says 'You have not concluded your merge (MERGE_HEAD exists)' — how do I get unstuck?
If you’re seeing this error
error: You have not concluded your merge (MERGE_HEAD exists).hint: Please, commit your changes before merging.fatal: Exiting because of unfinished merge.error: Cherry-picking is not possible because you have unmerged files.You’re in the right place — the fix is below.
Short answer
A merge you started is still open. Decide one of two things: finish it by staging the resolved files and committing, or throw it away with git merge --abort. Everything else is blocked until you do, because Git will not start a second operation on top of an unfinished one.
git merge --abort # forget the merge entirely
# or finish it:
git add . && git commit
Abort or conclude — Git will not let you do anything else first
Does this match your situation?
- 'error: You have not concluded your merge (MERGE_HEAD exists).'
- git pull, git checkout and git rebase all refuse to run.
- You started a merge days ago, got distracted, and forgot.
- 'fatal: Exiting because of unfinished merge.'
- git status shows 'You have unmerged paths' or 'All conflicts fixed but you are still merging'.
Step-by-step fix
Ask Git what state you are actually in
status distinguishes the two cases precisely, and the difference decides your next command. 'Unmerged paths' means conflicts are still open; 'All conflicts fixed but you are still merging' means everything is resolved and only the commit is missing.
step 1git status git diff --name-only --diff-filter=U # files still conflicted ls .git/MERGE_HEAD # the file causing the errorOption 1: abandon the merge
abort restores your branch and working directory to exactly the state before the merge began. This is the right answer whenever you no longer remember what you were merging or why.
step 2git merge --abort git status # should be cleanOption 2: finish it
Resolve any remaining conflicts, stage everything, and commit. Staging a conflicted file is how you declare it settled — there is no separate 'mark resolved' command.
step 3# edit each conflicted file, then: git add . git commit # the merge message is prepared for you # already resolved everything? git merge --continueWhen abort refuses
If the merge state is damaged — usually after a crash, a killed process or an IDE that wrote its own files — abort can fail. Resetting to HEAD achieves the same end, at the cost of any uncommitted work from before the merge.
step 4git reset --merge # still stuck (this discards uncommitted changes): git reset --hard HEADgit reset --hard destroys uncommitted work. Run git stash first if there is anything in the tree you want.
Last resort: remove the state file
MERGE_HEAD is just a file naming the commit being merged. Deleting it clears the flag, but leaves whatever the merge already wrote into your working tree, so use it only when the commands above have failed.
step 5rm -f .git/MERGE_HEAD .git/MERGE_MSG .git/MERGE_MODE git statusShow the Windows / PowerShell version
Windows / PowerShellRemove-Item -Force .git\MERGE_HEAD, .git\MERGE_MSG, .git\MERGE_MODE -ErrorAction SilentlyContinue
Why this works
Git records an in-progress merge by writing .git/MERGE_HEAD, a file containing the commit hash of whatever is being merged in. Its presence is what makes the next commit a merge commit with two parents, and it is also a lock: while it exists, pull, checkout, rebase and cherry-pick all refuse, because layering a second operation on an unfinished merge produces a history nobody can untangle afterwards. So the error is not a fault report — it is Git holding your place. Every route out consists of removing that file, and the difference between merge --abort, merge --continue and deleting it by hand is only how much care is taken with the working tree on the way.
If that didn’t work
- CHERRY_PICK_HEAD, REVERT_HEAD and rebase-merge cause identical blocking — check .git/ for those too.
- git rebase --abort and git cherry-pick --abort are the equivalents for those operations.
- Close your IDE or Git GUI first; some hold a lock or re-create the state as you clear it.
- git reflog shows where you were before the merge if you need to reconstruct it.
How to stop it happening again
- Finish or abort a merge in the same sitting — an open merge stays open indefinitely.
- Run git status before you start anything; it always names the operation in progress.
- Commit or stash before pulling, so merges do not start with a dirty tree.
- Put the merge state in your shell prompt — most Git prompt themes show MERGING.
Commands used in this guide
git mergeCombine another branch's history into the current one.
git statusShow what's changed, what's staged, and what Git is ignoring.
git resetMove the current branch pointer, optionally rewriting the index and your files.
git commitRecord everything currently staged as a permanent snapshot.
git cherry-pickCopy one specific commit onto your current branch.
Still stuck?
Search the full command reference and every other rescue guide — there are 76 of them, covering everything from detached HEAD to force-push disasters.
Browse all guides →Frequently asked questions
What does 'MERGE_HEAD exists' mean?
The file .git/MERGE_HEAD is present, which means a merge you started has not been concluded. Git blocks pull, checkout, rebase and cherry-pick until you either commit the merge or abort it.
How do I cancel an unfinished merge?
git merge --abort restores your branch and working directory to exactly the state before the merge started. If that fails because the state is damaged, git reset --merge is the fallback.
Is it safe to delete .git/MERGE_HEAD manually?
It clears the error, but it is the last resort. Deleting it leaves whatever the merge already wrote into your working tree, so you get a half-merged state with no record of it. Try merge --abort and reset --merge first.
Why can't I pull while a merge is in progress?
Because pull would start a second merge on top of an unfinished one, producing a state with no clean way back. Git refuses deliberately — conclude or abort the first merge and the pull will run normally.
What is the difference between git merge --abort and git reset --hard?
merge --abort is merge-aware: it restores the pre-merge state including uncommitted changes that were safely stashed away by the merge machinery. reset --hard just moves the branch and wipes the working tree, discarding anything uncommitted. Prefer abort.
Related rescue guides
Git says I have merge conflicts — how do I fix them?
Git pauses and marks the clashing sections with <<<<<<<, ======= and >>>>>>>. Edit each file to the version you actually want, delete the markers, git add the file, then git merge --continue. If it gets overwhelming, git merge --abort returns you to exactly where you started.
Read the fix →Always fixableHow do I undo a Git merge?
If the merge hasn't been pushed, git reset --hard HEAD~1 removes it cleanly. If it has been pushed, use git revert -m 1 <merge-hash> so history stays valid for everyone else. And if you're still in the middle of a conflicted merge, git merge --abort is all you need.
Read the fix →Always fixableGit says another git process seems to be running — how do I fix index.lock?
Git locks the index while it works and removes the lock when it finishes. A crashed command, a killed process or an editor's background Git integration can leave the lock behind. Confirm nothing is actually running, then delete .git/index.lock.
Read the fix →Always fixableGit won't let me pull because of local changes — how do I fix it?
Git is refusing to overwrite uncommitted edits to files the incoming commits also change. Commit them, stash them, or discard them — stashing is the reversible choice and takes one command.
Read the fix →