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

Are dependent pull requests in Github possible?

提问by fyr

Currently i am working on a really big pull request. In order to keep code-reviews somehow manageable the idea was to split the complete pull request in isolated parts, which however depend on each other.

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

An example would be:

一个例子是：

• Pull request 1: Create interfaces: Interface A & B and restructure code
• Pull request 2: Interface A implementation and Tests (depends on pull request1)
• Pull request 3: Interface B implementation and Tests (depends on pull request2)
• Pull request 4: Mixed test of Implementations (depends on 2 + 3)

• 拉取请求1：创建接口：接口A&B并重构代码
• 拉取请求 2：接口 A 实现和测试（取决于拉取请求 1）
• 拉取请求 3：接口 B 实现和测试（取决于拉取请求 2）
• 拉取请求 4：实现的混合测试（取决于 2 + 3）

Is there a way in Github to file all four pull requests at the same time with dependencies?

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

采纳答案by Alan Pierce

As far as I can see, this is impossible, and in my opinion it's one of the major downsides of GitHub compared with other code review tools. Gerrit automatically sets up dependent code reviews when you push commits that depend on each other, and in Phabricator it's more of a pain, but still possible.

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

It's also good to keep in mind that there multiple ways that people use GitHub PRs. The normal open source collaboration way is to fork a repo and submit a cross-repo pull request, but in other cases (e.g. within an organization), you might submit pull requests for diffs all within the same repository. I think within a single repository it's more reasonable to get something along the lines of dependent pull requests, since you can set up the commit/branch structure within that repo.

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

Here's a blog post that describes how to get some advantages of dependent pull requests, which I think requires all commits to be in the same repo: http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/

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

A summary:

总结：

• To submit 5 dependent pull requests, create a 5-level-deep branch hierarchy and submit each PR as as that branch based on the previous branch.
• To update review 2 of 5, push an update to branch 2, then do 3 merge operations to integrate the changes into reviews 3, 4, and 5.
• You need to land all changes at once, since GitHub doesn't support updating the target branch of PRs. In the example, all 5 code reviews were landed as a single commit.GitHub now supports updating the base branch of a PR, so the PRs can be landed one at a time.

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

That approach seems to work ok for giant changes that are best reviewed in smaller pieces (although maintaining an n-level-deep branch hierarchy is a pain compared with something like git rebase -i), but it doesn't really allow for a "code review pipeline" where you can have dependent diffs in different stages of review and can land earlier ones as they're reviewed.

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

Some other internet resources that seem to also call out the limitation:

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

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

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/

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

My understanding is that people using GitHub PRs generally just try to structure their workflow to not rely on dependent code reviews. Some examples:

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

• Instead of breaking up a change into independently-reviewable incremental steps, submit it as a monolithic code review that will land all at once. GitHub still lets you split code reviews up into multiple commits that the reviewer can view, but they can't be approved/landed independently.
• Try to structure your work so you make changes in unrelated parts of the code, and put them on independent branches that you can use to submit independent PRs. You can still keep a local branch with all changes applied using cherry-picking or other approaches.
• If you have a change that depends on an outstanding PR, simply wait for the PR to get accepted and merged before submitting the new PR. You could mention somewhere that you have another PR that depends on that one, and maybe that will motivate the code reviewer to get to that one earlier.

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