我们的团队使用Github上引入请求来管理我们的工作流程，就像what is described here。在手动审查已接受的合并请求后，我们偶尔需要恢复合并，因为它尚未准备好部署到我们的生产服务器。还原一个Git合并提交，然后恢复该还原
但是，如果开发者试图再次发出拉入请求，它不承认这些变化恢复，并认为该提交已经在主分支。它只会包括自恢复以来他们最近的提交，但我们真正想要的是重新引入所有提交的提交，以及他们的新作品。换句话说，我们喜欢重新发布原始Pull Request的方式。
由于Github的不支持该功能（即，既没有恢复的合并，也不撤消/重新发出原始的拉入请求），我目前如果还原还原合并。这感觉不对。
我可以用什么其他的方式来实现的git相同的目标？ （或者Github上，如果有可能）
我认为你的问题就在这里出现，因为当你正在处理的引入请求，你选择自动合并他们在GitHub上。在处理拉请求described in the documentation的三种建议方法中，您使用的是最后一个（“自动合并”），它只有recently implemented。就我个人而言，我认为这只适用于明显正确的无关紧要的请求。对于任何更复杂的，我想用第一种方法，即
这意味着合并版本只有在你测试它并决定t推动。如果你不想，你可以重新设置你的主分支到原来的位置。
由于利益的问题，它可能是值得一说的更多，如果你做最终不得不恢复一个令人遗憾的合并会发生什么，但还是希望有重新合并以后版本的选项该分支。虽然它可能会感觉错误，但据我所知，处理这种情况的最简单方法的确是恢复回复。您可以通过Linux Torvalds在this post from the Pro Git blog和another discussion of the same problem中找到关于此问题的更多讨论，这可能也会有所帮助。
嗨马克 - 我读过最近的2篇文章，并感激你提醒我他们。我很想实施你的建议，除非我们的组织成员没有在Github上拥有自己的分支，他们仅仅从我们的回购中克隆出来，因为我们的老板希望每个开发人员都将他们的工作推向特色分支，只是我们有一份副本他们的工作。但是，我可能能够在单个共享机器上设置所有“遥控器”，并让它们推动到我们可以测试的地方。最大的障碍将是部署/审查流程的自动化。感谢您的洞察！ –
@芯片城堡：没问题。事实上，如果他们只是推送到功能分支，它就更容易了 - 您不需要添加远程，只需执行“git fetch origin”并尝试从右边的远程跟踪分支进行合并。 –
嗯......我们当前的流程要求质量检查人员在CI通过后手动检查它。我需要将Jenkins配置为“git pull --rebase origin master”以获得最新的副本，然后签出功能分支和“git rebase -i”以确保在运行测试套件之前一切都是最新的。如果通过，我可以自动部署到测试服务器，我们的质量检查评估。然后，如果所有这些都通过了，我可以接受合并请求，因为这是合并到主服务器中的唯一操作。这可能有很大帮助。让我知道你的想法。谢谢！ –
我建议你们采取不同的方法。您恢复和恢复回复的工作流程似乎对我非常困惑。您试图解决的实际问题可以以不同方式解决。
我建议你改变你的工作流使用两个分支。一个稳定的分支（master）和一个开发分支（develop）。所有工作都进入develop分支，或进入单独的主题分支。拉请求总是针对develop分支提交，然后在批准时合并为develop。
master初始分支的develop。只要develop处于稳定状态，就会将其合并到master中。 master是当前的稳定版本。
我以前阅读过这篇文章，这是一个很好的方法，但它对我们的团队来说似乎并不适用。我们已经在一个合并到master（通过Github Pull Request）之后使用了特性分支和CI运行，因此拥有一个我们尝试了一段时间的开发分支只是更多的工作来管理。另外，即使在我们的测试套件中，有时候主人变得不稳定，所以它并没有真正帮助我们的团队。不过，我会继续记住这一点。再次感谢您的建议。 –
如果你得到一个分支功能团，你可以使用你喜欢的功能来重建候选版本。你不会需要“恢复合并”：
进一步阅读：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
请参阅评论以及额外的洞察力。它对我们非常有用。
如果您在本地尝试合并来自拉取请求的提交，并在测试之后决定您不想合并，那么为什么要还原合并，而不是仅仅将合并重置为合并之前？ （我假设您在合并拉取请求之后，但在决定是否保留之前不会发布您的主分支）。 –
一旦合并请求被接受，它就会自动合并到主人中，这样我们团队中的任何人都可以从那里拉出来任何时候。通过回复，我遵循了我在我的问题中引用的博文的建议，因为它允许我们简单地转到其他Pull请求并最小化工作流程中的瓶颈。我担心重置会让事情变得更糟，因为主服务器始终可供我们的回购协作者使用。 –
啊，所以你实际上接受了GitHub上的pull请求。 （要求GitHub实际执行合并的功能最近才添加）。相反，我会将建议的提交提取到本地存储库中，合并它们并在那里进行测试。如果您对此感到满意，那么您可以将拉取请求标记为在GitHub上接受。 –