GitHub 拉取请求分支重新基于检测。

Question

我正在寻找一种简单的方法，可以在通过 GitHub 网页界面合并之前找出拉取请求分支是否已经在当前主分支上重新制作。目前，我必须检查父提交哈希，并将其与最新的主提交哈希进行比较。我希望能看到一些真/假图标或类似内容，以避免合并未重制的分支。有任何建议或可能的插件/浏览器扩展程序等吗?

- Michal Vrchota

---

请检查我的答案，并告诉我你的问题中是否遗漏了任何信息。 - Tim Biegeleisen

Answer 1

我不知道是否有这样的插件可以检测拉取请求分支是否已经在主分支之上进行了变基。无论如何，在GitHub上合并拉取请求之前，您应该养成始终审核本地和主分支的习惯。但是我看到您的工作流程存在更大的根本问题。似乎您正在尝试通过GitHub将已经变基的功能分支合并到主分支中。这违背了变基的主要目的。

将本地功能分支变基到主分支的整个重点是“领先”主分支，以便您可以使用所有来自功能的提交快进主分支。一张图表可以更好地解释这一点：

master: A <- B
feature*: A <- B <- C <- D
(* after rebasing feature branch on master)

现在如果你发出git push origin feature:master，你将使用包含整个特性的所有提交的快进方式来更新主分支。现在主分支看起来就像特性分支一样：

master: A <- B <- C <- D

请注意，这里不涉及合并操作。你需要将每个提交从你的功能分支直接推到主分支上。另一方面，如果你通过 GitHub 拉取请求合并功能分支，主分支将会是以下状态：

master: A <- C <- M

在这里，M是包含你整个功能分支的合并提交，现在已经被压缩了。显然，这是两个非常不同的结果，你应该仔细考虑你的组织实际上希望在他们的Git工作流中得到什么。

最后，请注意GitHub喜欢强制使用基于合并的工作流程。如果你发现自己正在审查一个拉取请求，你应该意识到很可能你将会撤销某人为了将他的功能重新基于主分支而做出的仔细工作。在GitHub上使用rebase是可能的，但你必须绕过拉取请求来实现。

- Tim Biegeleisen