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

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

哪里A, B失败的提交和W -是恢复M

所以在我开始修复发现的问题之前，我选择W提交到我的分支

git cherry-pick -x W

然后在我的分支上恢复W提交

git revert W 

之后我可以继续修理。

最终的历史记录如下:

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

当我发送一个PR时，它会清楚地显示PR是撤销恢复，并添加一些新的提交。

你必须“还原还原”。取决于你是如何还原原始文件的，它可能不像听起来那么容易。看看关于这个话题的官方文件。

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

允许:

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

But does it all work? Sure it does. You can revert a merge, and from a purely technical angle, git did it very naturally and had no real troubles. It just considered it a change from "state before merge" to "state after merge", and that was it. Nothing complicated, nothing odd, nothing really dangerous. Git will do it without even thinking about it. So from a technical angle, there's nothing wrong with reverting a merge, but from a workflow angle it's something that you generally should try to avoid. If at all possible, for example, if you find a problem that got merged into the main tree, rather than revert the merge, try really hard to: bisect the problem down into the branch you merged, and just fix it, or try to revert the individual commit that caused it. Yes, it's more complex, and no, it's not always going to work (sometimes the answer is: "oops, I really shouldn't have merged it, because it wasn't ready yet, and I really need to undo all of the merge"). So then you really should revert the merge, but when you want to re-do the merge, you now need to do it by reverting the revert.

你可以在devel分支中使用这个命令来丢弃(撤销)错误的合并提交(而不是仅仅恢复它)，而不是使用git-revert。

git checkout devel
git reset --hard COMMIT_BEFORE_WRONG_MERGE

这也将相应地调整工作目录的内容。小心:

将您的更改保存在开发分支中(因为错误的合并)，因为它们 Too将被git-reset删除。所有提交都在您指定的之后 git重置参数将消失! 另外，如果您的更改已经从其他存储库中取出，则不要这样做 因为重置将改写历史。

我建议在尝试之前仔细研究git-reset手册页。

现在，重置后，你可以在devel重新应用你的更改，然后做

git checkout devel
git merge 28s

这将是一个真正的合并从28s到devel像最初的一个(现在是 从git的历史中删除)。

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

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

哪里A, B失败的提交和W -是恢复M

所以在我开始修复发现的问题之前，我选择W提交到我的分支

git cherry-pick -x W

然后在我的分支上恢复W提交

git revert W 

之后我可以继续修理。

最终的历史记录如下:

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

当我发送一个PR时，它会清楚地显示PR是撤销恢复，并添加一些新的提交。

要在不破坏工作流程的情况下还原还原:

创建一个develop的本地垃圾副本 在develop的本地副本上恢复恢复提交 将该副本合并到您的特性分支中，并将您的特性分支推到您的git服务器。

当你准备好了，你的特征分支现在应该可以正常合并了。唯一的缺点是在历史记录中会有一些额外的合并/恢复提交。

在最初的合并之前在提交时创建新的分支-称其为' development -base' 在' development -base'之上执行'develop'的交互式重基(即使它已经在顶部)。在交互重基期间，你将有机会删除合并提交和反转合并的提交，即从git历史中删除这两个事件

此时你将拥有一个干净的“开发”分支，你可以像往常一样将你的功能分支合并到其中。