github pull请求：提交范围的冲突建议？ [英] github pull requests: Conflicting advice on commit ranges?

问题描述

但是这种情况怎么样：

ul>

Dave是上游repo，master分支Dave / A

Satish分叉回购，创建分支B，并向Dave / A

Satish然后从Satish / B创建分支C，让我们假设 C需要B

Satish希望创建另一个拉取请求，这次是分支C

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

GitHub的建议似乎认为C应该适用于A：
$ b blockquote>

更改通知pull $ b $的基本存储库更改b请求。每个可以推送到基础存储库的用户都会收到
的电子邮件通知，并在他们的仪表板中看到他们下次登录时的
新的请求。

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

1. Satish希望 Dave 采取行动; Satish已经知道另一个分支了


2. 如果Dave仅应用B-> C，那么补丁程序甚至不能工作

但是这个 StackOverflow上的答案说的相反，应该将C应用于B.注意他的场景是 a-> b-> c-> d-> e ，而我的简单的 A-> B-> C 。

发出另一个请求。对于base，输入C的提交编号
，并为头部输入E（yours / master）。

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

对我来说，两个参数都有一定的意义。这是正确的？

我猜测答案是它取决于...，但我真的很感谢漫游。感觉这里至少有三个问题：

1. 通知对象


2. 是否全部拉取请求被假定为有效的功能


3. 每组变更的可见性/隔离性，便于检查





想法

解决方案

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

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



但是，在公关讯息中，必须明确说明该公关是否应该取代另一公关。





这样，原始回购项目经理可以分别尝试这些不同的PR，评估其效果，并选择适当的PR。

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



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:

1. Satish wants Dave to take action; Satish already knows about the other branch
2. 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:

1. Who gets notified
2. Whether or not all pull requests are assumed to be functional
3. 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.

这篇关于github pull请求：提交范围的冲突建议？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！