基于另一个 pull request （和 branch）创建 Github pull request（和 branch）

Question

基于另一个 pull request （和 branch）创建 Github pull request（和 branch）

3

我有一个需要帮助的工作流程。通常我会在 Github 上创建一个分支并开启一次拉取请求（标准程序）。但是，有时候我想创建另一个依赖于之前仍然开放的 PR 的 PR。我希望在第一个 PR 仍然开放的时候对第二个 PR 进行审查。

为了做到这一点，我首先会创建另一个分支（基于之前的分支），并开启一个请求将更改合并到第一个分支中。同时，如果我对第一个分支有更改（以解决第一个 PR 的评论），我会将它们提交到第一个分支，然后将它们变基到第二个分支中。然后，我会强制推送第一个分支和第二个分支到它们的远程上。

但问题是，第二个 PR 有时会显示第一个分支的更改。它是线性历史记录，我认为 Github 很困惑。我尝试使用奇怪的方法，在第二个 PR 中将分支更改为其他共同祖先分支，然后再将其更改回第一个分支，突然间从不应出现的第一个分支的更改消失了。

是否有方法可以防止发生这种问题？我从不希望第一个 PR 的更改出现在第二个 PR 中（作为提交）。我只希望第二个 PR 看起来像是将更改提交到第一个 PR。

在第一个 PR 合并后，我通常会进入第二个分支并 rebase --onto our_main_branch，然后更新 Github 上的第二个 PR，以请求将更改合并到 our_main_branch。我也欢迎任何有关更好工作流程的评论。

- imagineerThat

这个回答解决了你的问题吗？Github中是否支持依赖的Pull Requests？ - Inigo

1

我刚才重新阅读了你的问题，我觉得我可能误解了情况。我的下面的回答假设目标存储库不受您控制，您无法将其推送。但是，似乎您可以这样做，因为除非第一个PR的分支在上游repo中，否则您无法基于第一个PR打开第二个PR。你能否确认这是事实？ - Inigo

@Inigo 是的，我可以访问开放的PR并在上游repo上创建分支而无需获得批准。只有我们的main分支需要审核。我应该澄清这一点。这是我们公司内部的开发，不是开源的。 - imagineerThat

2个回答

4

不行，这样做没有意义

我知道你的意思，但你必须从上游仓库的角度来看待它。他们没有接受你的第一个PR。你的第二个PR包含了你的第一个PR。由于GitHub PR是独立的（不支持PR依赖性，即无法说：“此PR需要您首先接受此其他PR），因此上游仓库必须能够接受第二个PR，并且为了有意义，它必须包括第二个PR所依赖的所有提交。

但这没关系

只需在第二个PR的描述中清楚地说明它是第一个PR的超集。您可以要求仓库所有者按顺序接受它们，但他们也可以只接受您的第二个PR，因为它包含了两组更改。

另请参见：

- Inigo

这实际上是不正确的。事实证明，在GitHub上从现有PR分支创建一个分支并进行PR是完全合法且非常有效的。GitHub理解您要做什么并自动进行补偿。直到最近我才知道这一点。 - matt

@matt 你说的 "compensates automagically" 是什么意思？如果你指上游仓库可以接受两个PR并按顺序合并，那只是普通的git功能，因为第二个合并将自动排除已经合并的提交。如果你的意思是GitHub会跟踪PR依赖关系并防止PR2被接受，请提供一些链接。 - Inigo

我的意思是将合并目标从第一个特性分支更改为主分支。因此，提交的数量始终是正确的。 - matt

1

@matt 我意识到我误解了发帖者的情况。我习惯于在上游仓库上打开PR，而我没有推送权限，这意味着pr1分支只存在于我的fork中，而不是上游仓库，在这种情况下，没有办法基于第一个PR创建pr2分支--它将基于master，因此也会包括所有来自pr1的提交。无论如何，我已经要求澄清问题。你的观点对于一种情况是正确的，而我的观点对于另一种情况是正确的。 - Inigo

1

@Inigo，我认为这在你提到的情况下是有意义的，对于造成的困扰我感到抱歉。 - imagineerThat

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- matt · Accepted Answer

实际上，GitHub对这种情况处理得非常好。您只需要确保第二个PR在第一个PR之前没有被接受即可。

假设您从主分支（main）创建功能分支。那么您可以从main创建一个名为feature1的分支，并将其推送并请求合并到main。然后您想继续开发，所以您从feature1创建了一个名为feature2的分支。当您完成后，可能存在两种情况:

1. 在此期间，feature1 的 PR 获得批准并合并。在这种情况下，请拉取main，并将feature2 拉取下来并基于main重置提交历史，然后将 feature2 推送上去并请求将其合并到main.

2. 好了，现在让我们假设feature1仍在等待批准。听起来很糟糕，对吧？但没关系！无论如何都要推送feature2 ，并请求将其合并到feature1。它看起来正是您想要的! 这里有件美妙的事情。如果现在接受并合并了feature1，那么该 PR 将自动更改为将feature2 合并到main，这正是您一开始想要的。而且它看起来仍然非常理想。基本上，GitHub 在幕后为您执行了提交历史重置。