撤销 git 合并提交，然后撤销撤销

Question

我们的团队使用Github Pull Requests来管理工作流程，就像这里所描述的一样。在手动审核接受的Pull Request之后，我们偶尔需要撤销该合并，因为它还没有准备好部署到我们的生产服务器。

然而，如果开发人员尝试再次发布Pull Request，它不会识别这些更改已被撤销，并且认为提交已经在主分支中。它只会包括他们最近的提交自撤消以来，但我们真正想要的是重新引入所有被撤消的提交，以及他们的新工作。换句话说，我们希望有一种重新发布原始Pull Request的方法。

由于Github不支持此功能（即既不能撤销合并，也不能撤销/重新发布原始pull request），我目前正在撤销已撤销的合并。这感觉不对。

在git中，我可以使用什么其他方法来实现同样的目标？（如果可能的话，在Github上）

- Chip Castle

---

如果您在本地尝试合并拉取请求中的提交，并在测试后决定不想进行该合并，为什么要还原合并，而不是将主分支重置回合并之前？（我假设您在决定是否保留拉取请求之前合并但未发布您的主分支。） - Mark Longair

一旦合并请求被接受，它就会自动合并到主分支中，因此我们团队中的任何人都可以随时从那里拉取。通过还原，我遵循了我在问题中引用的博客文章的建议，因为它使我们能够简单地转移到其他合并请求并最小化工作流程中的瓶颈。我担心重置会使情况变得更糟，因为主分支始终可供我们的存储库协作者使用。 - Chip Castle

啊，所以你要在GitHub上接受这个拉取请求。 （最近添加了要求GitHub实际执行合并的功能。）相反，我会将建议的提交获取到您的本地存储库中，在那里进行合并和测试。如果您对此满意，那么您可以在GitHub上标记该拉取请求已被接受。 - Mark Longair

马克 - 你说得很对。我有点犹豫是否要在我们的流程中添加层级，因为过去它非常繁重，结果导致开发停滞不前。然而，你给了我一个想法：如果有人将功能分支推送到我们很少使用的开发服务器之一，我可以设置Jenkins运行CI规范。然后我可以防止一些问题从未潜入主分支。但是，仍然会有时候需要撤销或回退操作，所以我仍在寻找答案。感谢你的帮助。 - Chip Castle

现在我更好地理解了这个问题，我已经扩展了我的答案并将其恢复。如果可以的话，我同意使用Jenkins来测试功能分支是一个好主意。 - Mark Longair

Answer 1

我认为你在这里遇到问题是因为在处理拉取请求时，你选择了在GitHub上自动合并它们。在文档中描述的三种处理拉取请求的方式之一，你正在使用最后一种（“自动合并”），该方式仅最近实现。就我个人而言，我认为这只适用于明显正确的琐碎拉取请求。对于更复杂的内容，我想使用第一种方法，即：

• 将请求者的存储库添加为新的远程分支
• 从该远程分支获取
• 尝试合并
• 小心测试
• 如果你满意，推送结果

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

---

有趣的是，如果你最终不得不回退一个令人遗憾的合并操作，但仍然想保留重新合并该分支的选项，那么可能值得更多地谈论一下会发生什么。虽然这可能感觉不对，但据我所知，处理这种情况的最简单方法确实是还原回退操作。在Pro Git博客上的这篇文章和Linux Torvalds关于同一问题的另一篇讨论中可以找到更多关于此问题的讨论，也许对您有所帮助。

- Mark Longair

---

嗨，马克 - 我之前读过那两篇文章，很感谢你提醒我。我很想实施你的建议，但我们组织的成员都没有在 Github 上拥有自己的分支，他们只是从我们的仓库中克隆代码，因为我们的老板希望每个开发者将他们的工作推送到特性分支上，这样我们就有了他们工作的副本。不过，我可以在一个共享机器上设置所有的“远程分支”，让他们推送到这个机器上，以便我们进行测试。最大的难题将是自动化部署/审查流程。感谢你的见解！ - Chip Castle

@Chip Castle：没问题。实际上，如果他们只是推送到特性分支，那就更容易了 - 你不需要添加远程仓库，只需执行 git fetch origin 并尝试从正确的远程跟踪分支合并即可。 - Mark Longair

嗯...我们目前的流程需要QA人员在CI通过后手动审核。我需要配置Jenkins以“git pull --rebase origin master”获取最新副本，然后检出功能分支并“git rebase -i”以确保一切都是最新的，然后运行测试套件。如果测试通过，我可以将其自动部署到测试服务器上，供我们的QA进行审核。然后，如果所有这些都通过了，我就可以接受Pull Request，因为那是唯一会合并到主分支的操作。这可能会有很大帮助。请告诉我您对此的想法。谢谢！ - Chip Castle

Answer 2

我建议你们采取不同的方法。你们反复撤销和还原的工作流程对我来说非常混乱。你们试图解决的实际问题可以用不同的方式来解决。

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

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

这部分内容基于nvie's "A successful Git branching model"。

- igorw

---

我之前读过那篇文章，这绝对是一个很好的方法，但似乎并不适合我们的团队。我们已经使用功能分支和CI在合并到主分支后运行（通过Github Pull Request），因此尝试了一段时间的开发分支只是更多的管理工作。此外，即使我们有测试套件，有时主分支也会变得不稳定，所以它并没有真正帮助我们的团队。然而，我会记住这个建议。再次感谢您的建议。 - Chip Castle

Answer 3

如果您采用按功能分支的方式进行开发，就可以使用所需的功能重新构建发布候选版本。您将不需要“撤销合并”：

更多阅读：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR 请查看评论以获取更多见解。这对我们非常有效。

- Adam Dymitruk