还原一个 git 合并提交，然后还原还原答案

【问题标题】：Reverting a git merge commit, then reverting the revert还原一个 git 合并提交，然后还原还原
【发布时间】：2011-12-19 15:21:02
【问题描述】：

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

但是，如果开发人员再次尝试发出 Pull Request，它不会识别出这些更改已被还原，并且会看到提交已经在 master 分支中。它只会包括他们自恢复以来最近的提交，但我们真正想要的是重新引入所有已恢复的提交，以及他们的新工作。换句话说，我们喜欢一种重新发出原始拉取请求的方法。

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

在 git 中我可以使用哪些其他方法来实现相同的目标？（或 Github，如果可能的话）

【问题讨论】：

如果您已经在本地尝试合并来自拉取请求的提交，并且在测试后决定您还不想进行该合并，那么您为什么要恢复合并，而不是仅仅重置 master回到合并之前？（我假设您在合并拉取请求后但在决定是否保留它之前没有发布您的主分支。）
一旦拉取请求被接受，它会自动合并到主控中，所以我们团队中的任何人都可以随时从那里拉取。通过还原，我遵循了我在问题中引用的博客文章的建议，因为它允许我们简单地转移到其他拉取请求并最大限度地减少工作流程中的瓶颈。我担心重置会使事情变得更糟，因为我们的 repo 合作者总是可以使用 master。
啊，所以您实际上是在 GitHub 上接受拉取请求。（要求 GitHub 实际进行合并的功能是最近才添加的。）相反，我会将建议的提交提取到您的本地存储库中，合并它们并在那里进行测试。如果您对此感到满意，那么您可以在 GitHub 上将拉取请求标记为已接受。
马克 - 你说得很好。我有点犹豫是否要在我们的流程中添加层，因为它曾经非常繁重，因此开发陷入停顿。但是，您给了我一个想法：如果有人将功能分支推送到我们很少使用的开发服务器之一，我可以设置 Jenkins 来运行 CI 规范。然后我可以防止一些问题蔓延到主人身上。但是，有时我仍需要还原或撤消操作，因此我仍在寻找答案。感谢您的帮助。
现在我更好地理解了这一点，我扩展了我的答案并取消了它。我同意，如果可以的话，使用 Jenkins 测试功能分支是个好主意。

标签： git github git-revert

【解决方案1】：

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

将请求者的存储库添加为新远程
从远程获取
尝试合并
仔细测试
如果您满意，请推送结果

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

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

【讨论】：

嗨，马克 - 我以前读过最后两篇文章，很感激你提醒我这些文章。我很乐意实施您的建议，除了我们的组织成员在 Github 上没有自己的分叉，他们只是从我们的 repo 克隆，因为我们的老板希望每个开发人员都将他们的工作推到功能分支上，这样我们就有了一份他们的工作。但是，我也许可以在一台共享机器上设置所有“遥控器”，然后让它们推送到那里，以便我们进行测试。最大的障碍将是自动化部署/审查过程。感谢您的洞察力！
@Chip Castle：没问题。事实上，如果他们只是推送到功能分支，那就更容易了——您不需要添加远程，只需执行git fetch origin 并尝试从正确的远程跟踪分支合并。
嗯...我们当前的流程要求 QA 人员在我们的 CI 通过后手动对其进行审核。我需要将 Jenkins 配置为“git pull --rebase origin master”以获得最新副本，然后检查功能分支和“git rebase -i”以确保在运行测试套件之前一切都是最新的。如果通过了，我可以让它自动部署到我们的 QA 审查的测试服务器上。然后，如果所有这些都通过了，我就可以接受拉取请求，因为这是唯一会合并到 master 中的操作。这可能会有很大帮助。让我知道你对此的看法。谢谢！

【解决方案2】：

我建议你们采取不同的方法。您还原和还原还原的工作流程对我来说似乎很混乱。您尝试解决的实际问题可以采用不同的方式解决。

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

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

这大致基于nvie's "A successful Git branching model"。

【讨论】：

我以前读过那篇文章，这肯定是一个很好的方法，但对我们的团队来说似乎效果不佳。我们已经使用了特性分支，并且 CI 在一个合并到 master 之后运行（通过 Github 拉取请求），所以我们尝试了一段时间的开发分支只是更多的工作需要管理。另外，即使使用我们的测试套件，master 有时也会变得不稳定，所以它对我们的团队并没有太大帮助。但是，我会牢记这一点。再次感谢您的建议。

【解决方案3】：

如果您建立了一个按功能划分的团队，您可以使用您喜欢的功能重新构建一个候选版本。您不需要“还原合并”：

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

请参阅 cmets 以获得更多信息。它对我们非常有效。

【讨论】：