Git merge doesn't work as expected after a revert?-CodePudding

I've created a simplification of a scenario in which I'm trying to understand why it works like that.

Here is the timeline of commits:

At first I've created a new branch named dev feature - both had one commit:

Let's look at dev :

Then added another line and committed :

Then another one :

And another one :

Then I switched to feature branch and added "bad code" :

Then I've switched back to dev and merged feature to dev :

So now I decided to revert the merge commit :

git revert -m 1 2c618a9

(parent 1 is the dev branch) and the revert did work as expected.

However, When I try ( only for testing purposes) to re-merge the feature branch to dev , nothing seems to happen: and I do not see the bad commits again :

Question

As you can see, the bad commits are not entered again. Why is that ? What if I wanted to merge it again?

CodePudding user response：

git merge first looks at how commits are linked one to another :

if you look at your repo's history graph (the blue and red dots on the left of your screenshot), you can see that the result of git revert will :

keep the existing history (including the previous git merge feature)
add a new commit on top of that

So the next time you try to run git merge feature, git will say "oh, but feature is already merged into dev", and will do nothing more.

One possibility to "re merge" feature is to use git cherry-pick to select the commit(s) that you want to replay on dev :

git cherry-pick <bad commit>

# if there were several commits to 're merge' :
git cherry-pick <commit1> <commit2> ...