The git checkout command lets you navigate between the branches created by git branch . Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch.
Undoing the abort is basically redoing the merge. So, rerun the git merge to restart, solve the conflicts using git mergetool and finally run git commit to finalise the merge.
How to Undo a Merge Commit in Git. You can use the Git reset command to undo a merge. Firstly, you need to check for the commit hash (or id) so you can use it to go back to the previous commit. To check for the hash, run git log or git reflog .
By default git revert
refuses to revert a merge commit as what that actually means is ambiguous. I presume that your HEAD
is in fact a merge commit.
If you want to revert the merge commit, you have to specify which parent of the merge you want to consider to be the main trunk, i.e. what you want to revert to.
Often this will be parent number one, for example if you were on master
and did git merge unwanted
and then decided to revert the merge of unwanted
. The first parent would be your pre-merge master
branch and the second parent would be the tip of unwanted
.
In this case you could do:
git revert -m 1 HEAD
git cat-file -p [MERGE_COMMIT_ID]
will show the parent branches in order. The first one listed would be -m 1, the second -m 2.
Say the other guy created bar on top of foo, but you created baz in the meantime and then merged, giving a history of
$ git lola * 2582152 (HEAD, master) Merge branch 'otherguy' |\ | * c7256de (otherguy) bar * | b7e7176 baz |/ * 9968f79 foo
Note: git lola is a non-standard but useful alias.
No dice with git revert
:
$ git revert HEAD fatal: Commit 2582152... is a merge but no -m option was given.
Charles Bailey gave an excellent answer as usual. Using git revert
as in
$ git revert --no-edit -m 1 HEAD [master e900aad] Revert "Merge branch 'otherguy'" 0 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 bar
effectively deletes bar
and produces a history of
$ git lola * e900aad (HEAD, master) Revert "Merge branch 'otherguy'" * 2582152 Merge branch 'otherguy' |\ | * c7256de (otherguy) bar * | b7e7176 baz |/ * 9968f79 foo
But I suspect you want to throw away the merge commit:
$ git reset --hard HEAD^ HEAD is now at b7e7176 baz $ git lola * b7e7176 (HEAD, master) baz | * c7256de (otherguy) bar |/ * 9968f79 foo
As documented in the git rev-parse
manual
<rev>^
, e.g. HEAD^,v1.5.1^0
A suffix^
to a revision parameter means the first parent of that commit object.^<n>
means the n-th parent (i.e.<rev>^
is equivalent to<rev>^1
). As a special rule,<rev>^0
means the commit itself and is used when<rev>
is the object name of a tag object that refers to a commit object.
so before invoking git reset
, HEAD^
(or HEAD^1
) was b7e7176 and HEAD^2
was c7256de, i.e., respectively the first and second parents of the merge commit.
Be careful with git reset --hard
because it can destroy work.
I had this problem, the solution was to look at the commit graph (using gitk) and see that I had the following:
* commit I want to cherry-pick (x)
|\
| * branch I want to cherry-pick to (y)
* |
|/
* common parent (x)
I understand now that I want to do
git cherry-pick -m 2 mycommitsha
This is because -m 1
would merge based on the common parent where as -m 2
merges based on branch y, that is the one I want to cherry-pick to.
In the original question, the '-m option' of the git error was probably mistaken to denote a commit message. As explained in the other answers, use '-m n' to specify the nth parent of the merge to pick the parent you consider to be the main trunk.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With