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.

CodePudding user response：

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:

• How do you deal with new dependencies on an older pull request in Github?
• Good strategy to handle dependencies between sequential pull requests

CodePudding user response：

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.