在Git中重新执行恢复的合并

Question

我在这里遇到了一个小问题:我在Git中有一个特定于问题的分支28s，我将它合并到了通用的develop分支中。事实证明我做得太快了，所以我使用git-revert来撤销合并。然而，现在到了将28s合并到develop中的时候了，但是git-merge命令看到了原始的merge，并愉快地宣布一切都很好，分支已经合并。我现在该干啥？是否创建'Revert "Revert "28s -> develop"“‘提交？这似乎不是一个好的方法，但我现在想不出有其他的方法。

树结构的外观：

​

​

Answer 1

你必须“恢复原状”。取决于你是如何还原原始的，它可能并不像听起来那么容易。看看official document on this topic。

---o---o---o---M---x---x---W---x---Y
              /
      ---A---B-------------------C---D

要执行以下操作，请执行以下操作：

---o---o---o---M---x---x-------x-------*
              /                       /
      ---A---B-------------------C---D

但这一切都能正常工作吗？当然是这样。你可以恢复合并，从纯技术的角度来看，git做得非常自然，没有真正的麻烦。

它只是认为这是从“合并前的状态”到“合并后的状态”的变化，仅此而已。

没有什么复杂的，没有什么奇怪的，也没有什么真正危险的。Git会不假思索地做这件事。

因此，从技术角度来看，恢复合并没有错，但从工作流程的角度来看，通常应该尽量避免使用。

如果可能，例如，如果您发现合并到主树中的问题，而不是恢复合并，请尝试 hard to：

• 将问题一分为二到您合并的分支中，然后修复它，
• 或尝试恢复导致它的单个提交。

是的，它更复杂，不，它并不总是有效的(有时答案是：“哦，我真的不应该合并它，因为它还没有准备好，我真的需要撤销所有的合并”)。所以你真的应该恢复合并，但是当你想要重新进行合并时，你现在需要通过恢复恢复来完成。

Answer 2

让我们假设你有这样的历史

---o---o---o---M---W---x-------x-------*
              /                      
      ---A---B

其中A、B提交失败，W-是M的还原

因此，在我开始修复发现的问题之前，我会精挑细选地提交给我的分支

git cherry-pick -x W

然后在我的分支上恢复W commit

git revert W 

在我可以继续修复之后。

最终的历史可能如下所示：

---o---o---o---M---W---x-------x-------*
              /                       /     
      ---A---B---W---W`----------C---D

当我发送PR时，它会清楚地显示PR是undo revert，并添加了一些新的提交。

Answer 3

要在不过度破坏工作流的情况下还原还原，请执行以下操作：

• 创建develop
• 的本地垃圾桶副本还原develop
• 本地副本上的还原提交将该副本合并到您的功能分支中，并将您的功能分支推送到git服务器。

当您准备好时，您的功能分支现在应该能够正常合并。这里唯一的缺点是你的历史记录中会有一些额外的合并/恢复提交。