Github中的依赖拉取请求可能吗？

Question

目前我正在处理一个非常大的拉取请求.为了使代码评审在某种程度上易于管理,我们的想法是将完整的拉取请求拆分为孤立的部分,而这些部分依赖于彼此.

一个例子是:

在Github中是否有办法同时使用依赖项提交所有四个pull请求？

Answer 1

据我所知,这是不可能的,在我看来,与其他代码审查工具相比,这是GitHub的主要缺点之一.当你推送依赖于彼此的提交时,Gerrit会自动设置相关的代码评论,而在Phabricator中,它会更加痛苦,但仍然可能.

记住人们使用GitHub PR的多种方式也是很好的.正常的开源协作方式是分叉存储库并提交交叉回购请求,但在其他情况下(例如在组织内),您可以在同一存储库中提交差异的拉取请求.我认为在单个存储库中,获取依赖拉取请求的内容更合理,因为您可以在该存储库中设置提交/分支结构.

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

总结:

要提交5个相关拉取请求,请创建一个5级深度分支层次结构,并根据前一个分支提交每个PR作为该分支.
要更新第2条评论5,请将更新推送到分支2,然后执行3次合并操作以将更改集成到评论3,4和5中.
~~您需要一次登陆所有更改,因为GitHub不支持更新PR的目标分支.在该示例中,所有5个代码评审都作为单个提交登陆.~~GitHub现在支持更新PR的基本分支,因此PR可以一次登陆一个.

这种方法似乎适用于以较小的部分进行最佳审查的巨大变化(尽管维持n级深度分支层次结构与某种程度相比是一种痛苦git rebase -i),但它并不真正允许"代码审查管道"你可以在不同的审查阶段有依赖差异,并可以在审查时找到早期的差异.

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

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

而不是将更改分解为可独立审查的增量步骤,而是将其作为单一的代码审查提交,该审核将立即归档.GitHub仍然允许您将代码评审分成多个提交,审阅者可以查看,但不能单独批准/登陆.
尝试构建您的工作,以便对代码的不相关部分进行更改,并将它们放在可用于提交独立PR的独立分支上.您仍然可以使用采摘或其他方法保留本地分支,并应用所有更改.
如果您的变更取决于未完成的PR,只需等待PR接受并合并,然后再提交新的PR.你可以提到某个地方,你有另一个PR依赖于那个,也许这将激励代码审查者更早地到达那个.

另请参阅 https://wchargin.github.io/posts/managing-dependent-pull-requests/，了解处理相关拉取请求的有趣做法。 (2认同)
顺便说一句，这种情况是可能的。假设 PR B 依赖于 PR A，因此需要先合并 A，然后才能合并 B。您可以将 B 上的所有工作基于 A 正在使用的分支。现在，当合并 A 并删除分支 A 时，B 现在将指向 master（而不是 A）。这里：https://github.com/isaacs/github/issues/959#issuecomment-642838613 (2认同)