github 拉取请求：关于提交范围的建议冲突？

Question

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

但是这种情况呢：

• Dave 是上游仓库，主分支“Dave/A”
• Satish 分叉存储库，创建分支 B，并向 Dave/A 发送拉取请求
• Satish 然后从 Satish/B 创建分支 C，让我们假设 C 需要 B
• Satish 想要创建另一个拉取请求，这次是针对分支 C

我发现了两组相互冲突的建议（但可能对 B 的依赖不同）

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

更改基础存储库会更改收到拉取通知的人员 要求。每个可以推送到基础存储库的人都会收到一个 电子邮件通知并在他们的仪表板中查看新的拉取请求 下次登录时。

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

1. Satish 希望 Dave 采取行动； Satish 已经知道另一个分支
2. 如果 Dave 只应用 B->C，那么补丁甚至都不起作用

但是这个answer on StackOverflow 说的正好相反，应该将 C 应用于 B。请注意，他的场景是 a->b->c->d->e，而我更简单的 A->B->C。

提出另一个请求。对于基础，输入 C 的提交号， 对于头部，输入 E（你的/主人）。

这相当于我的场景中的 B->C 范围。

对我来说，这两个论点都有一定的意义。哪个正确？

我猜答案是“这取决于...”，但我真的很感激演练。感觉这里至少存在三个问题：

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

想法？？？

Answer 1

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

我更喜欢单独做 PR，因为他们的 intent 和 scope 不同。

但是，在 PR 信息中，必须明确说明该 PR 是否应该取代另一个 PR。

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

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