Github 中的依赖拉取请求是否可能？答案

【问题标题】：Are dependent pull requests in Github possible?Github 中的依赖拉取请求是否可能？
【发布时间】：2014-12-24 12:22:26
【问题描述】：

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

一个例子是：

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

【问题讨论】：

我通常只是引用依赖，然后将 PR 链接起来，审阅者就会知道。添加 PR 1。添加 PR 2，使用 PR 1 分支作为基础，并提及“这取决于 #1”。等等。无需同时将它们全部放入。

【解决方案1】：

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

请记住，人们使用 GitHub PR 有多种方式。正常的开源协作方式是分叉一个 repo 并提交一个跨 repo 拉取请求，但在其他情况下（例如在组织内），您可能会在同一个存储库中提交所有差异的拉取请求。我认为在单个存储库中获取依赖拉取请求的内容更合理，因为您可以在该存储库中设置提交/分支结构。

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

总结：

要提交 5 个依赖拉取请求，请创建一个 5 级深的分支层次结构，并将每个 PR 作为基于前一个分支的分支提交。
要更新评论 2 of 5，请将更新推送到分支 2，然后执行 3 次合并操作以将更改集成到评论 3、4 和 5。
~~您需要一次性完成所有更改，因为 GitHub 不支持更新 PR 的目标分支。在示例中，所有 5 次代码审查都作为一个提交登陆。~~ GitHub 现在支持更新 PR 的基础分支，因此可以一次登陆一个 PR。

这种方法似乎适用于最好以较小的部分进行审查的巨大更改（尽管与 git rebase -i 之类的东西相比，维护一个 n 级深的分支层次结构是一种痛苦），但它实际上并不允许一个“代码审查管道”，您可以在其中拥有不同审查阶段的依赖差异，并且可以在审查时找到较早的差异。

其他一些似乎也提到了限制的互联网资源：

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

与其将更改分解为可独立审查的增量步骤，不如将其提交为一次性完成的整体代码审查。 GitHub 仍然允许您将代码审查拆分为审查者可以查看的多个提交，但它们不能被独立批准/登陆。
尝试组织您的工作，以便对代码的不相关部分进行更改，并将它们放在可用于提交独立 PR 的独立分支上。您仍然可以保留一个本地分支，并使用樱桃采摘或其他方法应用所有更改。
如果您的更改依赖于未完成的 PR，只需等待 PR 被接受并合并，然后再提交新 PR。您可以在某处提及您有另一个 PR 依赖于该 PR，这可能会促使代码审查员更早地获得该 PR。

【讨论】：

另请参阅wchargin.github.io/posts/managing-dependent-pull-requests，了解有关处理相关拉取请求的有趣观点。
GitHub 的缺点：当然！有一个词表示必须首先修复或实施其他方面——prework。拆分 prework 可以说是正确提交的一部分，并且是规范，而不是 GitHub（和 GitLab）认为的例外。
顺便说一句，这种情况是可能的。假设 PR B 依赖于 PR A，因此需要先合并 A，然后才能合并 B。您可以将 B 上的所有工作基于 A 正在使用的分支。现在，当 A 被合并并且分支 A 被删除时，B 现在将指向 master（而不是 A）。这里：github.com/isaacs/github/issues/959#issuecomment-642838613

【解决方案2】：

我开源了一个工具来管理相关的拉取请求并帮助解决这种用例。

使用 SPR，您只需将四个提交添加到一个分支中，该工具就会为您创建和管理整个拉取请求堆栈。

【讨论】：