恢复git合并提交，然后恢复恢复

Question

我们的团队使用Github Pull请求来管理我们的工作流程，就像what is described here一样。在手动检查接受的拉取请求后，我们有时需要恢复合并，因为它还没有准备好部署到我们的生产服务器上。

然而，如果开发人员试图再次发出拉取请求，它不会识别这些更改已被恢复，并看到提交已经在主分支中。它将只包括他们最近的提交，因为恢复，但我们真正想要的是重新介绍所有的提交被恢复，加上他们的新工作。换句话说，我们喜欢一种重新发出原始拉取请求的方式。

由于Github不支持此功能(即既不恢复合并，也不撤消/重新发出原始的拉取请求)，我目前正在恢复恢复的合并。这感觉不对劲。

在git中，我还可以使用哪些其他方法来实现相同的目标？(如果可能，也可以使用Github )

Answer 1

我认为您的问题之所以出现在这里，是因为当您处理拉请求时，您选择在GitHub上自动合并它们。在三种建议的处理拉取请求的方法中，你使用的是最后一种(“described in the documentation”)，它只有recently implemented。就我个人而言，我认为这只适用于明显正确的微不足道的拉取请求。对于更复杂的情况，我想使用第一种方法，即

将请求者的存储库添加为来自该远程服务器的新remote

• fetching，尝试使用carefully

• pushing

• carefully

• pushing if

这意味着，合并后的版本只有在您测试并决定推送后才会公开。如果你不想这样做，你可以把你的主分支重置到它以前的位置。

有趣的是，如果您最终不得不恢复一个令人遗憾的合并，但仍然希望可以选择重新合并该分支的较新版本，那么可能有必要更多地讨论一下会发生什么。尽管它可能感觉是错误的，但据我所知，处理这种情况的最简单的方法确实是还原。你可以在Linux的this post from the Pro Git blog和another discussion of the same problem中找到更多关于这个问题的讨论，这也可能是有帮助的。

Answer 2

我建议你们采取一种不同的方法。您的恢复和恢复恢复的工作流程对我来说似乎非常令人困惑。你试图解决的实际问题可以用不同的方法来解决。

我建议你改变你的工作流程，使用两个分支。一个稳定分支(master)和一个开发分支(develop)。所有工作都进入develop分支，或者进入单独的主题分支。拉取请求总是针对develop分支提交，然后在批准后合并到develop中。

master最初是从develop分支出来的。一旦develop处于稳定状态，就将其合并到master中。master是当前的稳定版本。

这是松散地基于nvie's "A successful Git branching model"的。

Answer 3

如果你建立了一个每个功能分支的团队，你可以用你喜欢的功能重新构建一个发布候选版本。您将不需要“恢复合并”：

进一步阅读：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

请参阅评论以获得更多洞察力。这对我们来说真的很好。