Github 中是否可能存在依赖拉请求？

Update 2022: While GitHub still has no native support for dependent/stacked pull requests, a few tools now exist that make it easier to manage a GitHub-friendly hierarchy of branches. My favorite is ghstack, which takes a stack of commits and turns each one into its own branch that GitHub can understand without losing PR history. You can then edit, reorder, split, and drop commits using interactive rebase and the PRs will be updated accordingly.

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.

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.

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/

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.

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.

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://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:

• 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.