为什么请求请求会导致分叉位于上游？

Question

假设有一个名为array([[ 0.88865681, 0.57913325], [ 0.3128103 , 0.69217687]]) 的GitHub存储库。假设我有一个名为upstream/project的叉子。我对fork/project进行了一些更改，并向fork/project发出了拉动请求。接受请求请求后，为什么upstream/project在fork/project之后变成1个提交？

上游回购中的代码现在与我的fork中的代码匹配。为什么我必须再次从上游存储库中拉出以保持相同状态？不能使上游存储库与fork完全同步，而不是“超调”它吗？

我希望能得到一个答案，以解释该系统提供的优点或要求此工作流程的限制（视情况而定）。谢谢！

Answer 1

SLaks在评论中暗示，区别在于在upstream/project上进行的合并提交。

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

拉动时，fork/project首先获取该新提交，然后进行快速转发而无需合并。只有 then 都是相同的树。

关于该策略：

非常宽泛的图景是，由于所有合并提交，因此合并策略（在此讨论）更加嘈杂，并且在树结构方面更笨拙。另一方面，变基策略更精简但也更棘手，如果人们不小心使用它，就会遇到令人讨厌的局面。

要进一步研究“策略”部分，已经进行了很多比较，并给出了很好的答案，只需按照“合并/合并辩论”的方式进行搜索即可。

Answer 2

  

我希望能得到一个答案，以解释该系统提供的优点或要求此工作流程的限制（视情况而定）。

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

  

为什么上游不与快进合并？

合并提交/不快速转发策略对于合并PR非常有用，因为它允许在一个步骤中还原更改（因为只有一个提交，所以不考虑其中有多少个提交）原始分支）。仅此一项就足以使其成为首选策略。