当合并分支已合并并已恢复时，如何强制进行合并提交？

Question

In our repository, we are following a workflow based on git-flow. We had a release that was finished (installed in production), so the release branch was merged into master.

    B---C---D---E [release/1]
   /             \
  A---------------F [master]

  E - head of the release branch
  F - merge of release/1 into master

There was a problem in production, so the software was moved back to the previous version. Our deployment process keeps backups, so this was done independently of source control. At this point, the master branch did not match the software in production, so we reverted the commit that merged the release into master. This brought the head of master and the software deployed in production in-sync.

    B---C---D---E
   /             \
  A---------------F---G [master]

  G - revert of release, effectively bring master back to A

The release was found to not be the problem, so we re-installed that software to production. We did this by creating a new release branch on the same commit as the old release branch.

    B---C---D---E [release/2]
   /             \
  A---------------F---G [master]

However, when we closed the release branch, Git did not create a merge commit, because the head of the release branch points to a set of commit that are in master's history (via the original merge).

    B---C---D---E-------+
   /             \       \
  A---------------F---G---H

  H - merge of release/2 into master (this is what we want!!)

However, due to the revert that actual changes in that release are now missing. How can I force Git to merge the head of the release branch a 2nd time?

Answer 1

As you noted, git doesn't do the merge because it sees those commits are in the branch's history already. The revert is what's in the way.

I've hit this before. What you need to do is first revert the revert. That will remove the commit that removes the commits. :-)

git revert G

You then probably want to re-merge just to pick up anything that happened afterwards.

Answer 2

Generally speaking the "revert the revert" technique is the way to go.

You can force create a commit like you describe with something like the following. You will need to tweak the various HEAD references to get the values you want.

git update-ref HEAD $(git log --format=%B -n 1 HEAD~1 | git commit-tree -p HEAD -p HEAD~1^2 HEAD^{tree} -F -)

git update-ref HEAD - this should be head --format=%B -n 1 HEAD?? - using this one to just grab a random commit message commit-tree -p HEAD - this specifies where the first parent should point (G) -p HEAD~1^2- this specifies the second parent (release/2) HEAD~1^{TREE} - this needs to point to the commit that has a tree you want to use (commit F)