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

Question

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

一个例子是：

• 提取请求1 ：创建接口：接口A＆amp; B和重组代码
• 拉取请求2 ：接口实现和测试（取决于拉取请求1）
• 拉取请求3 ：接口B实施和测试（取决于拉取请求2）
• 提取请求4 ：实施的混合测试（取决于2 + 3）

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

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可以一次登陆。

这种方法似乎适用于以较小的部分进行最佳审查的巨大变化（尽管与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。你可以在某个地方提到你有另一个PR依赖于那个PR，也许这会激励代码审查者提前到达那个。

Answer 2

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

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

结帐：https://github.com/ejoffe/spr