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

Question 1

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

一个例子是：

Github中是否可以通过依赖项同时提交所有四个拉取请求？

Question 2

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

记住人们使用GitHub PR的方式也很不错。正常的开源协作方式是派生一个仓库并提交一个跨仓库的拉取请求，但是在其他情况下（例如，在一个组织内），您可以在同一存储库中提交所有差异的拉取请求。我认为在单个存储库中沿依赖的拉取请求进行操作较为合理，因为您可以在该存储库中设置提交/分支结构。

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

总结：

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

对于最好以较小片段进行最佳审查的大型更改，这种方法似乎行得通（尽管与之类的东西相比，保持n级深的分支层次结构是一件痛苦的事情git rebase -i），但实际上并不允许“代码审查管道”您可以在不同的审核阶段获得相关差异，并可以在审核之前找到较早的差异。

其他一些互联网资源似乎也指出了局限性：

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

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