为什么拉请求会导致分支落后于上游？

Question

为什么拉请求会导致分支落后于上游？

4

假设有一个名为upstream/project的GitHub存储库。假设我有一个名为fork/project的分支。我在fork/project中进行了一些更改，并发起了一个拉取请求到upstream/project。一旦拉取请求被接受，为什么fork/project会变成比upstream/project落后1个提交？

现在上游存储库中的代码与我的分支中的代码相匹配。为什么我必须再次从上游存储库拉取，最终处于同样的状态？难道不能将上游存储库完全与分支同步，而不是“超越”它吗？

我希望得到一个回答，解释这个系统提供的优势或要求这种工作流程的限制，无论哪种情况，谢谢！

- Tashus

2

由于合并提交。 - SLaks

@SLaks 合并提交是我所描述的情况。我的问题是为什么会发生这种情况。 - Tashus

1

@Tashus：因为这是上游选择合并您的PR的策略。它还有其他几个选项（至少对于仓库内PR），但它选择了那个。 - Sergio Tulentsev

请参见我对 https://dev59.com/b63la4cB1Zd3GeqPUOvF 的回答。 - torek

2个回答

1

我希望您能解释一下这个系统提供的优势或需要这种工作流程的限制，无论哪种情况。

如果您真正询问的是这个：

为什么上游没有快速合并？

合并提交/非快速前进策略非常有用于合并PR，因为它允许在一个步骤中撤销更改（因为只有一个提交，而不管原始分支中有多少个提交）。这就足以使它成为首选策略。

- Sergio Tulentsev

1

非常好的观点，我确实在问题中忽略了那一点。另外，你是不是指no-fast-forward策略对于合并PR非常有用呢？ - Romain Valeri

谢谢你们两位的回答。你们一起回答了我的问题。@RomainVALERI - Tashus

1

@Tashus：别忘了标记一个答案，无论哪个你认为更有帮助。 - Sergio Tulentsev

1

我有一个习惯，在接受之前等待24小时，以便全球的每个人都有机会发表意见。 :) - Tashus

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

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

- Romain Valeri · Accepted Answer

正如SLaks在评论中所暗示的那样，区别在于在upstream/project上进行了合并提交。

当您的拉取请求被接受时，分支被合并并在upstream/project上做出提交，但在您再次从上游拉取之前，fork/project不知道这一点。

当您进行拉取时，fork/project首先获取新提交，然后只需快进即可，无需合并。只有在此之后，两个树才相同。

关于策略：

非常广泛的图片是合并策略（在此讨论）在树结构方面更加嘈杂和有些笨重，因为所有合并提交。另一方面，rebase策略更加简洁，但也更加棘手，如果人们粗心使用它，就会陷入困境。

要深入了解“策略”部分，已经有很多比较优秀的答案，只需搜索“合并/变基辩论”即可。