github pull请求：提交范围上的冲突建议？

Question

我知道将分支用于多个拉取请求，这很好。

但是这个场景呢：

• Dave是上游回购，主要分支＆＃34; Dave / A＆＃34;
• Satish分叉回购，创建分支B，并向Dave / A发送拉取请求
• Satish然后从Satish / B创建分支C，让我们假设 C需要B
• Satish想要创建另一个拉取请求，这次是分支C

我发现了两组相互矛盾的建议（但也许对B的依赖性不同）

Advice from GitHub似乎说C应该适用于A：

  

更改基本存储库会更改通知拉取的人员   请求。每个可以推送到基础存储库的人都会收到   电子邮件通知，并在其信息中心中查看新的拉取请求   下次他们登录。

这似乎适用于这种情况有两个原因：

1. 萨蒂什希望戴夫采取行动;萨蒂什已经知道了另一个分支
2. 如果Dave只使用B-> C，则补丁将无法正常工作

但是这个answer on StackOverflow反过来说，C应该应用于B.注意他的场景是a->b->c->d->e，而不是我的简单A->B->C。

  

再提出要求。对于base，输入C的提交编号，   而对于头部，把E（你的/主人）。

这相当于我的方案中的B-> C范围。

对我来说，这两个论点都有一定道理。哪个正确？

我猜测答案是＆＃34;这取决于......＆＃34;，但我非常欣赏这次演练。感觉这里至少有三个问题：

1. 谁收到通知
2. 是否假定所有拉取请求都是正常的
3. 每组更改的可见性/隔离，以便于检查

思想???

Answer 1

这是一个沟通问题，不仅仅是Git问题。

我更喜欢制作单独的PR，因为他们的意图和范围不同。

但是，在PR消息中，必须清楚地说明PR是否假设取代另一个PR。

这样，原始的repo项目经理可以分别尝试那些不同的PR，测量它们的效果，并选择合适的PR。

然后，他可以根据他或她最终选择的PR的工作，要求初始贡献者重做他们的PR（在他们的同一分支上）。