3

I have a workflow that needs some assistance. I usually create a branch and open a pull request on github (standard procedure). However, sometimes I want to create another PR that depends on the PR from earlier that is still open. I want reviews on the second PR while the first PR is still open.

To do that, I first create another branch (off of the earlier branch) and open a PR that requests changes into the first branch. Meanwhile, if I have changes for the first branch (addressing the first PR's comments), I commit them into the first branch, and then rebase them into the second branch. I then force push the first branch and second branch to their remotes.

However, the problem is that the second PR sometimes shows changes from the first branch. It's a linear history and I think github is confused. I try this weird thing where I change the branch in the second PR to some other common ancestor branch, and then change it back to the first branch, and suddenly the changes from the first branch that shouldn't have appeared disappear.

Is there a way to prevent this problem from happening? I never want the first PR's changes to appear in the second PR (as commits). I just want the second PR to look like it is committing changes into the first PR.

After the first PR is merged, I then usually go into the second branch and rebase --onto our_main_branch and update the second PR in github to request merging changes into our_main_branch. I welcome any comments on a better workflow as well.

imagineerThat
  • 5,293
  • 7
  • 42
  • 78
  • Does this answer your question? [Are dependent pull requests in Github possible?](https://stackoverflow.com/questions/26619478/are-dependent-pull-requests-in-github-possible) – Inigo Dec 01 '21 at 01:47
  • 1
    I just reread your question and I think I may have misunderstood the situation. My answer below assumed that the target repo was out of your control, that you did not have push privileges into it. But it appears that you do, since you cannot open a second PR based on the first PR unless the branch for the first PR is in the upstream repo. Can you please confirm this is the case? – Inigo Dec 02 '21 at 00:28
  • @Inigo yes, I do have access to open PR's and create branches without approval on the upstream repo. It is only our `main` branch that requires reviews. I should have clarified this. This is development within my company, not open source. – imagineerThat Dec 02 '21 at 19:48

2 Answers2

9

Actually, GitHub copes perfectly well with this situation. You just have to make sure the second PR doesn't get accepted before the first.

So let's say you work on feature branches off of main. So from main you make a branch feature1 and push it and ask for a PR merging into main. Then you want to keep working, so you make a branch feature2 off of feature1, and when you finish, there are two possibilities:

  • In the meantime, feature1 PR got approved and merged. In that case, pull main and rebase feature2 onto main, and push feature2 and ask for a PR merging into main.

  • Okay, now let's assume instead that feature1 is still sitting waiting for approval. Sounds bad, eh? But no problem! Just push feature2 anyway, and ask for a PR merging into feature1. It will look just the way you want! — And here is the wonderful part. If feature1 is now accepted and merged, the PR will automatically change to a merge into main, which is what you wanted all along. And it will still look exactly the way you want. Basically GitHub has done the rebase for you behind the scenes.

matt
  • 515,959
  • 87
  • 875
  • 1,141
4

No, and it wouldn't make sense

I hear what you're saying, but you have to look at it from the upstream repo's perspective. They haven't accepted your first PR. Your second PR includes your first PR. Since GitHub PR's are independent (there is no support for PR dependencies, i.e. a way to say: "This PR requires that you first accept this other PR), the upstream repo has to be able to accept the second PR, and for that to make sense, it has to include all the commits the second PR depends on.

But that's ok

Just make it clear in your second PR that it is a superset of your first PR in the description. You can ask them repo owner to accept them in order, but it's also perfectly fine for them to accept just your second PR since it includes both sets of changes.

See also:

Inigo
  • 12,186
  • 5
  • 41
  • 70
  • This is actually not true. It turns out it is totally legal, and works great, to make a PR from a branch off of an existing PR branch on GitHub. GitHub understands what you are trying to do and compensates automagically. I had no idea about this until quite recently. – matt Dec 01 '21 at 01:58
  • @matt what do you mean "compensates automagically"? If you mean the upstream repo can accept the two PRs in order, that's just normal git functionality, as the second merge will automatically exclude already merged commits. If you mean GitHub keeps track of PR dependencies and prevents PR2 from being accepted, please supply some links. – Inigo Dec 01 '21 at 02:31
  • I mean it changes the merge target from the first feature branch to the main branch. And so the number of commits is always right. – matt Dec 01 '21 at 03:25
  • 1
    @matt I realize that I misunderstood the poster's scenario. I'm so used to opening PRs on upstream repos for which I have no push privileges, which means the `pr1` branch only exists in my fork, not in the upstream repo, in which case there is no way to base a `pr2` branch on the first pr -- it would be based on `master` and it would thus include all the commits from pr1 as well. Anyway, I asked for clarification on the question. You're point is true for one scenario, and my is true for another – Inigo Dec 02 '21 at 00:35
  • 1
    @Inigo I think that makes sense for the case you mentioned, sorry for the confusion. – imagineerThat Dec 02 '21 at 19:52