A typical merge commit would be shown as below in the git log command output.
commit dddfd0b6d529bfcdcd6515555ea1dcf186fe338 Merge: 6b5619b 40ad694 Author: Raja Anbazhagan <[email protected]> Date: Fri Jun 7 03:11:23 2019 +0530 Merge branch 'xyz' into 'develop' Here, You can see that the second line contains two short hashes. 6b5619b and 40ad694. Both of these are the top most commits of the branches that got merged.
Here 6b5619b is the top most commit id of the branch develop. And 40ad694 is the top most commit of the feature branch xyz.
I am telling you all this is because this information is important for what I am going to explain next.
When you are resetting or reverting a commit, it will try to figure out what had changed in that commit by comparing it to its ancestor commit.
In this case there are two ancestors 6b5619b and 40ad694 and GIT is now not sure from which ancestor it has to find the diff.
In these cases, the user will have to provide the appropriate parent commit id for the process to continue. Which is done with a flag -m followed by an ordinal number that represents where the parent commit id resides in the merge commit.
for my sample merge commit, possible -m values are 1 and 2. 1 for 6b5619b and 2 for 40ad694.
So if you want to revert your code on your develop branch, you should do
git revert -m 1 <merge-commit> With -m 1 the git revert happens in relevance to develop branch (first parent of the merge). Passing -m 2 would result in the revert happening in relevance to the feature branch xxx
In general cases -m 1 whatis the one you should use. But that is not true for all the cases.