I ran into a merge conflict. How can I abort the merge?

Question

I used git pull and had a merge conflict:

unmerged:   _widget.html.erb

You are in the middle of a conflicted merge.

I know that the other version of the file is good and that mine is bad so all my changes should be abandoned. How can I do this?

Solution 1

Since your pull was unsuccessful then HEAD (not HEAD^) is the last "valid" commit on your branch:

git reset --hard HEAD

The other piece you want is to let their changes over-ride your changes.

Older versions of git allowed you to use the "theirs" merge strategy:

git pull --strategy=theirs remote_branch

But this has since been removed, as explained in this message by Junio Hamano (the Git maintainer). As noted in the link, instead you would do this:

git fetch origin
git reset --hard origin

Solution 2

If your git version is >= 1.6.1, you can use git reset --merge.

Also, as @Michael Johnson mentions, if your git version is >= 1.7.4, you can also use git merge --abort.

As always, make sure you have no uncommitted changes before you start a merge.

From the git merge man page

git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

MERGE_HEAD is present when a merge is in progress.

Also, regarding uncommitted changes when starting a merge:

If you have changes you don't want to commit before starting a merge, just git stash them before the merge and git stash pop after finishing the merge or aborting it.

Solution 3

git merge --abort

Abort the current conflict resolution process, and try to reconstruct the pre-merge state.

If there were uncommitted worktree changes present when the merge started, git merge --abort will in some cases be unable to reconstruct these changes. It is therefore recommended to always commit or stash your changes before running git merge.

git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

http://www.git-scm.com/docs/git-merge

Solution 4

I think it's git reset you need.

Beware that git revert means something very different to, say, svn revert - in Subversion the revert will discard your (uncommitted) changes, returning the file to the current version from the repository, whereas git revert "undoes" a commit.

git reset should do the equivalent of svn revert, that is, discard your unwanted changes.

Solution 5

In this particular use case, you don't really want to abort the merge, just resolve the conflict in a particular way.

There is no particular need to reset and perform a merge with a different strategy, either. The conflicts have been correctly highlighted by git and the requirement to accept the other sides changes is only for this one file.

For an unmerged file in a conflict git makes available the common base, local and remote versions of the file in the index. (This is where they are read from for use in a 3-way diff tool by git mergetool.) You can use git show to view them.

# common base:
git show :1:_widget.html.erb

# 'ours'
git show :2:_widget.html.erb

# 'theirs'
git show :3:_widget.html.erb

The simplest way to resolve the conflict to use the remote version verbatim is:

git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb

Or, with git >= 1.6.1:

git checkout --theirs _widget.html.erb

View more solutions

Comments

[rjmunro]

I realise this is a super-old question, but do you want to abort the whole merge, and leave the branch you were merging unmerged, or just ignore this one file as part of a larger merge, letting all the other files merge in as normal? To me, your title implies the former, your question body wants the latter. The answers do both, without making things clear.

[eQ19]

I got similar case on commit saying that automatic merge failed; fix conflicts and then commit the result: [rejected] gh-pages -> gh-pages (non-fast-forward)

[Amicable]

Gwyn, it could be useful to select an accepted answer here. The top voted one is a bit less safe than some of the more up to date solutions, so I think it would help to highlight others over it :)

[Peter]

thanks for the hint. doesn't this smack of a poor git user interface, though?

[CB Bailey]

@Peter: I'm not convinced. The desired result is achievable with a few basic commands with simple options. What improvements would you suggest?

[Peter]

I think the git 1.6.1 command makes a lot of sense, and is good. That's exactly what I would have wanted. I think the pre-1.6.1 solution is inelegant and requires knowledge about other parts of git that should be separated from the merge resolution process. But the new version is great!

[Kzqai]

Instead of doing a hard reset, you could bring it to a more granular level by doing: git fetch origin --> git reset origin (soft reset, your changes are still present) --> git checkout file_to_use_their_version_of another_file (steamroll your own changes back to match the origin) I never use git pull any more. Since in a fight between my latest code and the origin, the origin should always win, I always git fetch and git rebase origin. This actually makes my merges and conflicts few and far between.

[Pat Notz]

I agree. I also like to fetch first, and then examine the upstream changes (git log ..@{upstream} or git diff ..@{upstream}). After that, like you, I'll rebase my work.

[ThanksForYourHelp]

I found this approach useful when I accidentally merged to a git-svn branch, which doesn't handle that nicely. Squash merges or cherry picks are better when working with git-svn tracking branches. In effect my solution turns a merge into a squash merge after the fact.

[lzap]

In addition to that I recommend to run "git clean -f" if you still have some untracked files you want to clean.

[EoghanM]

instead of git reset --hard origin, git branch -r (pick the branch name), git reset --hard remote/branch worked for me.

[conny]

Interesting - but the manual scares me. When exactly is it appropriate to use? When would you have to specify the optional <commit>? #GitMoment :-o

[Carl]

You'd typically use this when you want to redo the merge from the start. I have never had to specify the optional commit myself, so the default (no optional <commit>) is just fine.

[Jay Taylor]

I wish this answer had more votes! At this point, it seems like the most relevant solution in many cases.

[Matt Ball]

As noted in a more recent answer, as of version 1.6.1, it is possible to use 'git reset --merge'

[mlt]

I used git merge -X theirs remote_branch instead of git pull --strategy=theirs remote_branch as theirs looks like an option of recursive

[srcspider]

There is no strategy theirs.

[Michael Johnson]

This has been available since git v1.7.4. It's an alias for git reset --merge.

[T3rm1]

Even with uncommited changes git was able to restore the state before the merge. Nice!

[Tikhon Jelvis]

Is git merge --abort just a synonym for git reset --merge? The name certainly makes more sense, but does it have the same functionality?

[Jon L.]

@mlt, theirs is indeed an option of recursive, it doesn't exist as a strategy of it's own (in current git), per the docs.

[Ewoks]

what is here actually meant by "failed merge"? Merge with conflicts or something else? Or to rephrase it: when is MERGE_HEAD not present? My follow-up question is there to understand better use of "git reset --merge".

[Ben Liyanage]

git reset --merge saved my bacon. Amazing!

[Daniel Cassidy]

git merge --abort is far preferable.

[ks1322]

git merge --abort doesn't work with octopus merge conflict, only git reset --merge does work.

[lnarasimhan]

git fetch origin followed by git reset --hard origin/master did the trick. BTW I 'am using git version 2.13.6 (Apple Git-96)

[nitzel]

@Ewoks git stash apply caused a merge conflict for me but git merge --abort did not help while git reset --merge did.

[juanmf]

@Kzqai I use git pull --rebase once I have locally committed (normally amending so I have 1 commit per feature, at least until I push) my changes.

[Fouad Boukredine]

Best answer to the question

[Mecki]

How would this be different to a soft reset? A soft reset also resets the repository to head but doesn't touch the working copy.

[ThanksForYourHelp]

Yes, but does "git reset --soft someref" spring to mind when your goal is "How can I abort the merge?". How do you know what to use for someref? Hence "git merge --abort" which does the right thing and is obviously named which is refreshing for Git.

[sk8forether]

I would like to note for the next poor soul who ends up in my situation that when git merge --abort did not work, these steps did.

[Adrian Bartholomew]

The OP is obviously using the command line. There is zero value to your post.

[Kamil Kiełczewski]

I agree that this is obvious that OP use command line - but people who not use command line but sourcetree and have similar problem find this question at the top in google (like I) - so for such persons this answer has value - this is why I left it here :)

[BjornW]

Had to use this to resolve a failed merge, I had no MERGE_HEAD for some reason so git merge --abort didn't work.

[Luis]

Heads up to anyone else considering this: MERGE_HEAD is not present when your merge happened because of stash pop; and reset --merge will delete your untracked files. See stackoverflow.com/a/67099267/1623757

[Kheldar]

What I needed after a failed merge from a tag to master...

[Carmine Tambascia]

No really because a merge conflict could be for different reasons. Nevertheless behind what you do on GUI in SourceTree, are running command line command. On top I would say be careful with GUI because any unexpected such low internet connection will cause your GUI to go out of sync with git index and you may face a corrupted flow with a git.lock that is hard to "fix" except to remove it, and abort the merge conflict

[Steve Summit]

Well, without commenting on whether it's "poor" or not, let me say that I would never have guessed that a syntax involving 'show' and :1:, :2:, and :3: was the way to recover the base and two "tip" files, but I am immensely glad to know of this technique, so: thank you very much!