Git - 如何恢复空的合并提交？

Question

Someone created an empty merge commit( develop to broken-branch ).

When I try to run git revert <commit> -m 1 I receive a message:

$ git revert <commit> -m 1
Already up to date!
On branch my-brach
Your branch is up to date with 'origin/broken-brach'.

nothing to commit, working tree clean

I need to remove this commit since merging this branch to develop simply reverts all changes from develop that were ignored during the empty merge.

Also, the commit is already published:(

UPDATE: The commit is shared across the team. And there are plenty of commits after that

Answer 1

I need to remove this commit...

Actually, you don't need to remove it. Removing it would solve one problem but can create others.

... since merging this branch to develop simply reverts all changes from develop that were ignored during the empty merge.

I believe I know what you mean to say here. That's not quite correct technically, but captures the essence of the problem.

Also, the commit is already published:(

UPDATE: The commit is shared across the team. And there are plenty of commits after that

This is where the can create other [problems] part I mentioned in my first sentence comes in. It may be too hard to remove the senseless merge, so you might want a different approach. First, let's describe the problem properly , though.

We start with two lines of development, with a series of commits on each, and two branch names to identify the last commit in each of these lines of development:

       o--o--o   <-- develop
      /
...--*
      \
       o--o--o   <-- br2

I've used one of the two names you used ( develop ) and a more neutral name for the second branch ( br2 ). Note that both branches descend from some common starting point, which I have marked here as commit "star" * . I've arbitrarily chosen to represent the branches as having three commits since that point on each branch, though any number of commits would work. The key is that this starred commit is the best common ancestor of the two branches.

If we were to do a normal merge operation now, we could pick one of the two branches with git checkout or git switch and run git merge on the other branch. To represent our mistake, though, I'm going to first create a new name , mistake , and point it at the last commit that is on branch br2 as of this point:

       o--o--o   <-- develop
      /
...--*
      \
       o--o--o   <-- br2, mistake (HEAD)

We now have three branches, including the branch on which we'll make a mistake (on purpose): we will run:

git merge -s ours develop

This will create a new merge commit , which I will represent using the letter M . A merge commit is like any other commit in that it has a source code snapshot of all files and a first parent, but unlike ordinary commits, it then has a second parent too. The first parent of new merge M will be the commit that is at the tip of br2 (and currently at the tip of mistake ) and the second parent will be the commit that is at the tip of develop . For easier reference later, let me call these two commits A and B :

       o--o--A   <-- develop
      /       \
...--*         M   <-- mistake (HEAD)
      \       /
       o--o--B   <-- br2

Because of the -s ours option, the snapshot in commit M exactly matches the snapshot in the last commit on br2 . That is, if we get the actual hash IDs of M and B and run:

git diff <hash-of-M> <hash-of-B>

the difference will be completely empty . (If it's not completely empty, we can still have a problem later, it's just that the problem might be a little smaller.) If we had left out the -s ours option, we would have a normal merge and we would not have set up a trap for ourselves in the future. But we are trying to reproduce your issue.

Now let's make more commits on both develop and mistake , in the usual way:

       o--o--A--C--D--E   <-- develop
      /       \
...--*         M--F--G--H   <-- mistake
      \       /
       o--o--B   <-- br2

If we now check out one of these two—for instance, develop —and run git merge on the other, Git does the same sort of thing we should have let it do last time: it finds the merge base between commits E and H . The problem here is that this is commit A , not commit * .

What Git does now, then, is compare what's in the merge base—commit A —with what's in the two branch-tip commits. That is, it runs, in effect:

git diff --find-renames <hash-of-A> <hash-of-E>   # what we changed
git diff --find-renames <hash-of-A> <hash-of-H>   # what they changed

Now, what exactly is in commit H ? Well, commit H is built by taking what's in M —which matches what's in B —and making some change in F , then making some change in G , then making some change in H . So the "what they changed" part starts with removing whatever is in the two o commits along the top line , then adding some more changes.

Meanwhile, what's in A -vs- E is whatever got changed in C , D , and E . Git combines these two changes: add C+D+E, but also add M+F+G+H . The add M step means take away what's in the two top-line o commits .

Note that the merge base between commits A and B is commit * . If we had let Git combine the work in the three commits leading to A with the work in the three commits leading to B —if we had not made a mistake , in other words—we'd be in great shape now. The snapshot in M would combine these bits of work. It would not take away changes from the two unnamed o commits along the top. But we deliberately didn't use commit * . We made the snapshot in M match the snapshot in B . We set up a time bomb, and our later merge explodes the time bomb.

Note that this problem is independent of the branch names . If we didn't use the name mistake , we would now have:

       o--o--A--C--D--E   <-- develop
      /       \
...--*         M--F--G--H   <-- br2
      \       /
       o--o--B

This is the same commit graph and therefore contains the same time bomb. The bomb is embedded in the commits. The names we use to find the commits are quite irrelevant.

How to fix the problem

There are several different ways around this problem. None of them is the Single One Right Way. All of them need to take the mistake into account. The mistake was to set up a time bomb, so that this future merge will drop several commits—the unnamed ones along the top row.

All ways to fix this involve creating new commits. (That's pretty much the only thing you ever do in Git, after all.) The question is which new commits to create. We can choose any of several actions:

• Copy a whole bunch of commits, fixing our earlier mistake as we go.
• Go ahead and merge now, then copy the individual commits that got dropped.
• Temporarily "fake out" the lack of a merge, using git replace . (I'm not going to show this method, as it's complex and has repeatability issues.)
• Others that you can imagine and try out for yourself.

Suppose we start with this:

       o--o--A--C--D--E   <-- develop
      /       \
...--*         M--F--G--H   <-- mistake
      \       /
       o--o--B   <-- br2

That is, even if we used the name br2 all along, let's create a new name mistake pointing to commit H , then use git branch or git reset --hard to force the name br2 to point back to commit B :

git checkout -b mistake br2; git branch -f br2 <hash-of-B>

Now we'll git checkout commit B under the name br2 :

git checkout br2

to get:

       o--o--A--C--D--E   <-- develop
      /       \
...--*         M--F--G--H   <-- mistake
      \       /
       o--o--B   <-- br2 (HEAD)

Method 1: copy commits, omitting the mistake

We can now simply copy every commit after M , without bothering with commit M , using an en-masse git cherry-pick :

       o--o--A--C--D--E   <-- develop
      /       \
...--*         M--F--G--H   <-- mistake
      \       /
       o--o--B--F'-G'-H'   <-- br2 (HEAD)

This might have a bunch of merge conflicts. If so, we'll have to solve each one.

Having done this, we can now erase the name mistake entirely, if we wish, and pretend commits MFGH never even existed:

       o--o--A--C--D--E   <-- develop
      /
...--*
      \
       o--o--B--F'-G'-H'   <-- br2 (HEAD)

This amounts to removing the merge via git rebase . The rebase command is in essence just an en-masse cherry-pick with some branch name juggling, which is exactly what we just did. Now we can merge commits E and H' in the normal way, using commit * as their merge base.

Note that we can leave the name mistake around, and maybe create a new name br3 , so that we get:

       o--o--A--C--D----E   <-- develop
      /       \          \
...--*         M--F--G--H \ <-- mistake
      \       /            \
       o--o--B--F'-G'-H'----M2   <-- br3 (HEAD)

or use develop as the branch that acquires the merge:

       o--o--A--C--D--E-----M2   <-- develop (HEAD)
      /       \            /
...--*         M--F--G--H / <-- mistake
      \       /          /
       o--o--B--F'-G'---H'   <-- br3

The advantage to creating a new name is that this way, branch names only move forward. Any time we use git branch -f or git rebase to move a branch name "backwards" first, then forwards, that means that every clone of our repository must adjust any work they have done that depends on the names moving forward.

Method two: merge, then copy commits to fix the mistake

Alternatively, let's look at starting with this:

       o--o--A--C--D--E   <-- develop
      /       \
...--*         M--F--G--H   <-- br2 (HEAD)
      \       /
       o--o--B

and just doing the merge now. We run git checkout develop and then git merge br2 and get:

       o--o--A--C--D--E---M2   <-- develop (HEAD)
      /       \          /
...--*         M--F--G--H   <-- br2
      \       /
       o--o--B

where commit M2 drops commits oo from the top, just as we noted. So now let's just cherry-pick them in:

git cherry-pick <hash1>
git cherry-pick <hash2>

The merge itself and the two cherry-picks might have merge conflicts. If so, that's OK; we just solve them. Now we have:

       o--o--A--C--D--E---M2-o'-o'  <-- develop (HEAD)
      /       \          /
...--*         M--F--G--H   <-- br2
      \       /
       o--o--B

and the snapshot in the last o' commit has what we want.

Method 3: copy the develop branch to bypass the mistake

Last, we can use one other mass copy trick. Instead of mass-copying FGH onto the end of B (whether by git cherry-pick or by git rebase ), let's mass-copy the entire top line . For sanity sake, let's use a new name, keeping develop as the old one, for the moment. We'll call the new branch fixup and we'll point it to commit * , which is before the screwup starts:

     ..................   <-- fixup (HEAD)
     .
     . o--o--A--C--D--E   <-- develop
     ./       \
...--*         M--F--G--H   <-- br2
      \       /
       o--o--B

Now, with fixup checked out (as indicated by HEAD above), we force Git to copy commits ooCDE using git cherry-pick :

git cherry-pick HEAD..develop

This has no merge conflicts (ever) because these commits easily apply here, so now we have:

       o'-o'-A'-C'-D'-E'  <-- fixup (HEAD)
      /
     | o--o--A--C--D--E   <-- develop
     |/       \
...--*         M--F--G--H   <-- br2
      \       /
       o--o--B

We can now do the merge with git merge br2 . The merge base here is commit * , not commit A —commit A isn't on fixup —so the merge has the desired source snapshot:

       o'-o'-A'-C'-D'-E'----M2  <-- fixup (HEAD)
      /                    /
     | o--o--A--C--D--E   /  <-- develop
     |/       \          /
...--*         M--F--G--H   <-- br2
      \       /
       o--o--B

We're now ready to do one last merge, with:

git checkout develop
git merge fixup

The merge base of these two commits is commit * again, so Git compares * vs E to see what we changed, and * vs M2 to see what "they" changed. What "they" changed includes everything we changed, so with luck, this merge goes well, and makes a new commit automatically:

       o'-o'-A'-C'-D'-E'----M2  <-- fixup
      /                    /  \
     | o--o--A--C--D--E---/----M3  <-- develop (HEAD)
     |/       \          /
...--*         M--F--G--H   <-- br2
      \       /
       o--o--B

We can now delete the name fixup entirely. All we have done is add new commits: one to develop , and a whole new chain that we called fixup while we were doing it.

Answer 2

If the commit is published, but not really shared (for example: if no one else on your team has its work depending on broken-branch ), you are perhaps in a situation where you can force push:

# spot <good sha> in the history of 'broken-branch' :
git push origin --force-with-lease <good sha>:broken-branch

# additionally, fix your local repo and your colleague's local repo

---

Otherwise: you can run git restore to create a new commit on top of the merge, with the exact same content as what was on broken-branch before the merge:

# again : spot <good sha> in the history of 'broken-branch' :
git restore <good sha>
git commit
git push

note : git restore was added fairly recently to git (v2.27), if you are stuck with an older git and can't upgrade, replace it with:

git read-tree <good sha>
git commit
...

Answer 3

Is this the last commit in your branch? If yes - you can do the following: git reset --hard HEAD~1 and then git push -f

If not - you can try with: git rebase -i HEAD~{X}

X is the number of commits from the last commit in the branch to the commit you want to revert.

Then you can try and drop the commit.