CODEWITHSUNDEEP
gitgithubpull-request
fyr
fyr

Reputation: 20869

Are dependent pull requests in GitHub possible?

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:

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

Upvotes: 125

Views: 53307

Answers (2)

ilyesAj
ilyesAj

Reputation: 544

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

Upvotes: 3

Alan Pierce
Alan Pierce

Reputation: 4193

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.

Upvotes: 105

Related Questions