我们的团队使用 Github Pull Requests 来管理我们的工作流程，就像这里描述的一样。在手动审查接受的拉取请求后，我们有时需要恢复该合并，因为它还没有准备好部署到我们的生产服务器。
但是，如果开发人员尝试再次发出拉取请求，它不会识别这些更改已被还原，并且会看到提交已经在主分支中。它只会包括他们自恢复以来最近的提交，但我们真正想要的是重新引入所有已恢复的提交，以及他们的新工作。换句话说，我们喜欢一种重新发出原始拉取请求的方法。
由于 Github 不支持此功能（即，既不恢复合并，也不撤消/重新发出原始拉取请求），我目前正在恢复恢复的合并。这感觉不对。
我可以使用哪些其他方式在 git 中实现相同的目标？（或 Github，如果可能的话）
我认为您的问题出现在这里是因为当您处理拉取请求时，您选择在 GitHub 上自动合并它们。在文档中描述的处理拉取请求的三种建议方法中，您使用的是最后一种（“自动合并”），它是最近才实现的。就个人而言，我认为这仅适用于明显正确的琐碎拉取请求。对于更复杂的事情，我想使用第一种方法，即
这意味着合并后的版本只有在您测试并决定推送后才会公开。如果您不想这样做，您可以将您的主分支重置为之前的位置。
有趣的是，如果您最终不得不恢复令人遗憾的合并，但仍然希望可以选择重新合并该分支的更高版本，那么可能值得多说一下会发生什么。尽管可能感觉不对，但据我了解，处理这种情况的最简单方法确实是还原还原。您可以在 Pro Git 博客的这篇文章中找到更多关于此问题的讨论，以及Linux Torvalds对同一问题的另一次讨论，这可能也有帮助。
我建议你们采取不同的方法。您还原和还原还原的工作流程对我来说似乎很混乱。您尝试解决的实际问题可以以不同的方式解决。
我建议您更改工作流程以使用两个分支。一个稳定分支 ( master) 和一个开发分支 ( develop)。所有工作都进入develop分支，或进入单独的主题分支。拉取请求总是针对分支提交，然后在批准develop后合并。develop
master最初是从develop. 一旦develop处于稳定状态，您将其合并到master. master是当前的稳定版本。
这大致基于nvie 的“成功的 Git 分支模型”。
如果你得到一个按功能分支的团，你可以用你喜欢的功能重建一个候选版本。您不需要“恢复合并”：
进一步阅读： https: //plus.google.com/109096274754593704906/posts/R4qkeyRadLR
请参阅评论以及更多见解。它对我们非常有效。