Are dependent pull requests in GitHub possible?

Question

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 into 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 request 1).
• Pull request 3: Interface B implementation and Tests (depends on pull request 2).
• Pull request 4: Mixed test of Implementations (depends on 2 + 3).

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

Undeviating

I typically just reference the dependency, then the PRs will be linked, and the reviewers will know. Add PR 1. Add PR 2, use the PR 1 branch as the base, and mention "this depends on #1". And so on. There's no need to put them all in simultaneously. – Stripteaser

@Stripteaser Reviewers will know but automated tests could fail if a PR depends on another PR. – Lysippus

@DannyW.Adair Each PR's branch is based on its dependency PR's branch. For example, PR2 will work because its base is PR1. – Stripteaser

That's one way of doing it but not how the OP explained it. Why else did they write for PR4 "depends on 2 + 3" - it could just be based on PR3 if you go that route. – Lysippus

Answer 1

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.

Stonebroke

Also see wchargin.github.io/posts/managing-dependent-pull-requests for an interesting take on handling dependent pull requests. – Coronado

Downside of GitHub: Certainly! There is a word for having to fix or implement other aspects first – prework. Splitting out prework is arguably part of doing commits properly, and is the norm, not an exception, as GitHub (and GitLab) think it is. – Iliad

Btw, this sort of is possible. Let's say PR B depends on PR A, so that A needs to be merged before B can. You can base all the work on B on the branch that A was using. Now, when A is merged, and branch A deleted, B will now point to master (instead of A). Here: github.com/isaacs/github/issues/959#issuecomment-642838613 – Chute

Answer 2

Let me add an answer here since I experienced pretty same use case in a project with multiple dependencies.

There is no simple/native way to make it in GitHub. you can mention PRs within a comment and you will have some links between them but it will just be links between them and no real dependencies.

I opt out of using dependencies-action. This action guarantees dependencies based on PR's opening comment. If the action succeeds, the PR will be mergeable; otherwise, it fails and blocks the merge.

In order to use this workflow, you just need to add the following yaml file within your .github/workflows

on: [pull_request]

jobs:
  check_dependencies:
    runs-on: ubuntu-latest
    name: Check Dependencies
    steps:
    - uses: gregsdennis/[email protected]
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

If you have your PRs spread across multiple repositories, you can add the workflow within all the repos.

Now that your workflow is set, you can explicitly mention your dependencies:

on PR1: no additional comments

on PR2: add: Depends on [PR1](link to your pr 1)

on PR3: add: Depends on [PR2](link to your pr 2)

on PR4: add:

• Depends on [PR2](link to your pr 2)
• Depends on [PR3](link to your pr 3)

Here you go, you explicitly declaring dependencies based on a single comment within a PR. This also applies to issues ;)

If you need a step-by-step guide, you can go to this blog

Incorruption