如何在接受任何一个请求之前在现有请求之上堆叠第二个请求？

我想用两个不同的拉请求来呈现回购所有者，第二个基于第一回。如何在接受任何一个请求之前在现有请求之上堆叠第二个请求？

我有一个现有的拉力要求在回购挂起（即我没有）。

我想基于我现有的拉动请求的进一步改变。

git push --set-upstream origin B

：

master -> A -> B

我基于I用于A.

git branch -b B A

我有推上游与分支在我的叉一个新分支使我的B中的变化

当我尝试通过github UI为B创建一个pull请求时，它给了我A +在单个pull请求中的变化。

如果我尝试从这个命令行：

hub pull-request -b A

它不工作，因为A是不是在上游回购的一个分支，只是在我的叉子。

我应该为目前有两个引入请求回购所有者不同的方式来做，一个堆叠在另一个之上？

来源

2016-09-23 Thomas David Baker

我试图在这里遵循的步骤：https://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/但他的'枢纽拉请求-b A'不为我工作。可能是因为他没有分叉。 –

拉取请求的目的是整体接受/拒绝。如果业主想要拒绝第一个PR并接受第二个PR，会发生什么？也许你应该创建一个单一的PR？ –

嗯。我想他们可以点击进入单独的提交，如果他们想要审查理智。所以你认为我只是误解了语义上的拉取请求？在单一的拉动请求中堆叠一大堆变化是否可行，是否符合ettiquette？ –

在一次拉动请求中叠加大量更改是可以的，ettiquette-wise？

如果你的第二次改变绝对取决于第一次，那么...是的。

话虽这么说，你应该先解决PR A，这意味着原来的回购应该评估，接受和合并的第一PR的维护者。

在此期间，你可以为B中的新的分支，根据A，并推动该分支到你的叉子，但你不应该做一个新的PR之前，首先得到解决。
特别是如果第一个PR被拒绝。

在OP的情况：

我结束了治疗我所有的堆叠变化一个拉请求，如果他们想合理审查，他们可以点击进入每一个通过提交一个

那当所有这些变化都可以被视为一个新的大变革时，这是有道理的。
最佳实践建议进行小的增量更改，但在此情况下，向现有PR添加提交（因为实际上无法“堆叠PR”）是向开发过程前进的方式。

来源

2016-09-23 15:12:03 VonC

这听起来相当合理。但是我宁愿有一堆等待他们的变化，而不是让他们审核并合并，然后再发送给他们。我们处于不同的时区，这可能导致我们在几天内来回跳舞。我最终将所有堆叠的更改视为一个请求，如果他们想要明智地进行审查，他们可以逐个点击进入每个提交。我仍然认为能够堆叠pull请求会很好，但我会发现这是不可能的！谢谢！ –

@ThomasDavidBaker你的解决方案对你来说非常好。我已将您的结论纳入答案中，以获得更多的知名度。 – VonC

谢谢。我真的不想把这个标记为公认的答案，因为真正的答案确实是“理想的工作流程不被github支持”。另外，如果存在的话，我想给某人一个更好的东西进行突袭的机会。 –

如何在接受任何一个请求之前在现有请求之上堆叠第二个请求？

回答

相关问题