Last Updated: 2021-05-15
git reset --hard ORIG_HEAD (more idiomatic)
Option 2: Use
git reflog to see commit one prior to merge, then reset
git reset --hard SHA.
git revert -m 1 SHA
Danger zone: Imagine that the reverted merge was for a branch called
It has two commits that were originally merged into
master. These broke
master, thus the reason for wanting to revert the merge. The effect of this
revert was to create a reverse patch (that we will call W) of bringing in these
two commits. Now, work continues in both the
including a third commit in
feature that fixes the bug. Now, when
merged into master again, unfortunately it will not include the previous two
commits prior to the fix (since these were reverted by the merge commit W).
Why does this mess happen? Because while the revert undoes the data, it does not undo the history. Future merges will see the previous merge (even though it was later reverted) and view it as the last shared state. Therefore it is unwise to view a revert of a merge commit as an undo since it does not undo history.
What to do? When you want to bring the new branch in, you need to revert the
revert (W), i.e.
git revert W (creating commit Y). The overall effect means
the history would be equivalent to to not having either W or Y in it at all =>
merging the feature branch again would bring in all three commits. For a better
explanation read Linus Torvalds answer