git - Github 中的依赖 pull 请求是否可行？

Question

目前我正在处理一个非常大的 pull 请求。为了以某种方式保持代码审查的可管理性，我们的想法是将完整的 pull 请求拆分为独立的部分，但这些部分相互依赖。

一个例子是:

• pull 请求 1:创建接口(interface):接口(interface) A 和 B 并重组代码
• pull 请求 2:接口(interface) A 实现和测试(取决于 pull 请求 1)
• pull 请求 3:接口(interface) B 实现和测试(取决于 pull 请求 2)
• pull 请求 4:实现的混合测试(取决于 2 + 3)

Github 中有没有一种方法可以同时提交所有四个带有依赖项的 pull 请求？

Answer 1

2022 年更新:虽然 GitHub 仍然没有对依赖/堆叠 pull 请求的原生支持，但现在有一些工具可以更轻松地管理对 GitHub 友好的分支层次结构。我最喜欢的是ghstack ，它采用一堆提交并将每个提交变成它自己的分支，GitHub 可以在不丢失 PR 历史记录的情况下理解它。然后，您可以使用交互式 rebase 编辑、重新排序、拆分和删除提交，PR 将相应更新。

---

据我所知，这是不可能的，在我看来，与其他代码审查工具相比，这是 GitHub 的主要缺点之一。当您推送相互依赖的提交时，Gerrit 会自动设置依赖代码审查，而在 Phabricator 中，这更痛苦，但仍然有可能。

同样要记住，人们使用 GitHub PR 的方式有多种。正常的开源协作方式是 fork 一个存储库并提交一个跨存储库的 pull 请求，但在其他情况下(例如在一个组织内)，您可能会在同一存储库中提交所有差异的 pull 请求。我认为在单个存储库中，按照依赖 pull 请求的方式获得一些东西更合理，因为您可以在该存储库中设置提交/分支结构。

这是一篇描述如何获得依赖 pull 请求的一些优势的博客文章，我认为这需要所有提交都在同一个 repo 中: http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/

总结:

• 要提交 5 个相关的 pull 请求，请创建一个 5 级深的分支层次结构，并根据前一个分支将每个 PR 作为该分支提交。
• 要更新评论 2(共 5 条)，将更新推送到分支 2，然后执行 3 次 merge 操作以将更改整合到评论 3、4 和 5 中。
• 您需要一次完成所有更改，因为 GitHub 不支持更新 PR 的目标分支。在示例中，所有 5 次代码审查都作为单个提交登陆。GitHub 现在支持更新 PR 的基础分支，因此 PR 可以一次登陆一个。

这种方法似乎适用于最好以较小的部分进行审查的巨大更改(尽管与 git rebase -i 之类的东西相比，维护一个 n 级深的分支层次结构是一件痛苦的事情)，但它并没有真正允许“代码审查管道”，您可以在审查的不同阶段有依赖差异，并且可以在审查时更早地登陆。

其他一些似乎也指出了限制的互联网资源:

https://www.quora.com/Is-there-a-good-system-for-adding-multiple-pull-requests-to-GitHub

https://muffinresearch.co.uk/how-do-you-deal-with-dependent-branches-on-github/

我的理解是，使用 GitHub PR 的人通常只是尝试构建他们的工作流程，而不依赖于依赖代码审查。一些例子:

• 与其将更改分解为可独立审查的增量步骤，不如将其作为一次全部完成的整体代码审查提交。 GitHub 仍然允许您将代码审查分成审查者可以查看的多个提交，但它们不能被独立批准/登陆。
• 尝试构建您的工作，以便在代码的不相关部分进行更改，并将它们放在您可以用来提交独立 PR 的独立分支上。您仍然可以保留一个本地分支，并使用精选或其他方法应用所有更改。
• 如果您的更改依赖于未完成的 PR，只需等待 PR 被接受并 merge ，然后再提交新的 PR。你可以在某个地方提到你有另一个 PR 依赖于那个 PR，也许这会激励代码审查者更早地到达那个 PR。