I know about using branches for multiple pull requests, that's fine.
But what about this scenario:
- Dave is the upstream repo, master branch "Dave/A"
- Satish forks the repo, creates branch B, and sends a pull request against Dave/A
- Satish then creates branch C from Satish/B, and let's assume that C requires B
- Satish wants to create another pull request, this time for branch C
I've found two conflicting sets of advice (but perhaps the dependency on B is different)
Advice from GitHub seems to say C should be applied against A:
Changing the base repository changes who is notified of the pull request. Everyone that can push to the base repository will receive an email notification and see the new pull request in their dashboard the next time they sign in.
This would seem to apply in this case for two reasons:
- Satish wants Dave to take action; Satish already knows about the other branch
- If Dave were to only apply B->C then the patch wouldn't even work
But this answer on StackOverflow says the opposite, that C should be applied against B. Note that his scenario is a->b->c->d->e, vs. my simpler A->B->C.
Make another request. For the base, type in the commit number of C, and for the head, put E (yours/master).
This is equivalent to B->C range in my scenario.
To me, both arguments make some amount of sense. Which is correct?
I'm guessing that the answer is "it depends...", but I'd really appreciate the walkthrough. It feels like there's at least three issues here:
- Who gets notified
- Whether or not all pull requests are assumed to be functional
- Visibility / isolation of each set of changes, for easier inspection
Thoughts???
It is a communication problem, more than a Git issue.
I prefer making separate PR, as their intent and scope differs.
But, in the PR message, one must clearly states if that PR is suppose to supersede another PR.
That way, the original repo project manager can try those different PR separately, gauging their effects, and select the appropriate one.
He can then ask initial contributors to redo their PR (on their same branch) based on the work of the PR he or she finally selected.
来源：https://stackoverflow.com/questions/23159860/github-pull-requests-conflicting-advice-on-commit-ranges