I used git pull and had a merge conflict:
unmerged: some_file.txt You are in the middle of a conflicted merge. How do I abandon my changes to the file and keep only the pulled changes?
14 Answers
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 
12 Comments
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.
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
Daniel Cassidy
git merge --abort is far preferable. |
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.
6 Comments
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.
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?
ks1322
git merge --abort doesn't work with octopus merge conflict, only git reset --merge does work. |
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 --abortwill 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 --abortis equivalent togit reset --mergewhenMERGE_HEADis present.
2 Comments
Michael Johnson
This has been available since git v1.7.4. It's an alias for git reset --merge.
Melebius
This is not available if the merge conflict was caused by another command, e.g.
git stash pop.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.
1 Comment
pqnet
to be clear:
git revert does not undo the commit, it undo the changes that that commit introduced. And it does that by creating a new commit with the opposite changes than the target commit.For git >= 1.6.1:
git merge --abort For older versions of git, this will do the job:
git reset --merge or
git reset --hard 
1 Comment
sv_lane
git reset --hard worked when git merge --abort kept telling I had uncommitted changes.You can either abort the merge step:
git merge --abort else you can keep your changes (on which branch you are)
git checkout --ours file1 file2 ... otherwise you can keep other branch changes
git checkout --theirs file1 file2 ... 
Comments
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 
4 Comments
Peter
thanks for the hint. doesn't this smack of a poor git user interface, though?
Lara 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!
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!Comments suggest that git reset --merge is an alias for git merge --abort. It is worth noticing that git merge --abort is only equivalent to git reset --merge given that a MERGE_HEAD is present. This can be read in the git help for merge command.
git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.
After a failed merge, when there is no MERGE_HEAD, the failed merge can be undone with git reset --merge, but not necessarily with git merge --abort. They are not only old and new syntax for the same thing.
Personally, I find git reset --merge much more powerful for scenarios similar to the described one, and failed merges in general.
5 Comments
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".
nitzel
@Ewoks
git stash apply caused a merge conflict for me but git merge --abort did not help while git reset --merge did.
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...
If you end up with merge conflict and doesn't have anything to commit, but still a merge error is being displayed. After applying all the below mentioned commands,
git reset --hard HEAD git pull --strategy=theirs remote_branch git fetch origin git reset --hard origin Please remove
.git\index.lock
File [cut paste to some other location in case of recovery] and then enter any of below command depending on which version you want.
git reset --hard HEAD git reset --hard origin Hope that helps!!!
Might not be what the OP wanted, but for me I tried to merge a stable branch to a feature branch and there were too many conflicts. I didn't manage to reset the changes since the HEAD was changed by many commits, So the easy solution was to force checkout to a stable branch. you can then checkout to the other branch and it will be as it was before the merge.
git checkout -f master
git checkout side-branch
1 Comment
sigma1510
git checkout -f main for the post-2020 copy-pasters.An alternative, which preserves the state of the working copy is:
git stash git merge --abort git stash pop I generally advise against this, because it is effectively like merging in Subversion as it throws away the branch relationships in the following commit.
4 Comments
Alain O'Dea
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.
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.
Alain O'Dea
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.
Since Git 1.6.1.3 git checkout has been able to checkout from either side of a merge:
git checkout --theirs _widget.html.erb Comments
To avoid getting into this sort of trouble one can expand on the git merge --abort approach and create a separate test branch before merging.
Case: You have a topic branch, it wasn't merged because you got distracted/something came up/you know but it is (or was) ready.
Now is it possible to merge this into master?
Work in a test branch to estimate / find a solution, then abandon the test branch and apply the solution in the topic branch.
# Checkout the topic branch git checkout topic-branch-1 # Create a _test_ branch on top of this git checkout -b test # Attempt to merge master git merge master # If it fails you can abandon the merge git merge --abort git checkout - git branch -D test # we don't care about this branch really... Work on resolving the conflict.
# Checkout the topic branch git checkout topic-branch-1 # Create a _test_ branch on top of this git checkout -b test # Attempt to merge master git merge master # resolve conflicts, run it through tests, etc # then git commit <conflict-resolving> # You *could* now even create a separate test branch on top of master # and see if you are able to merge git checkout master git checkout -b master-test git merge test Finally checkout the topic branch again, apply the fix from the test branch and continue with the PR. Lastly delete the test and master-test.
Involved? Yes, but it won't mess with my topic or master branch until I'm good and ready.
Comments
I found the following worked for me (revert a single file to pre-merge state):
git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset* 
[rejected] gh-pages -> gh-pages (non-fast-forward)git merge --abort?