假设有一个名为upstream/project的GitHub存储库。假设我有一个名为fork/project的叉子。我对fork/project进行了一些更改，并向upstream/project发起拉取请求。一旦拉取请求被接受，为什么fork/project成为upstream/project背后的1次提交？
上游仓库中的代码现在与我的fork中的代码匹配。为什么我必须再次从上游回购中拉出来以最终处于同一状态？难道上游存储库不能与fork完全同步，而不是“过度”它吗？
我希望得到一个答案，解释该系统提供的优势或需要此工作流程的限制，无论哪种情况。谢谢！
我希望得到一个答案，解释该系统提供的优势或需要此工作流程的限制，无论哪种情况。
如果你真正问的是这个：
为什么上游没有与快进合并？
合并提交/不快进策略对于合并PR非常有用，因为它允许仅在一个步骤中恢复更改（因为只有一个提交，不管原始分支中有多少提交）。仅这一点就足以使其成为首选战略。
正如SLaks在评论中暗示的那样，区别在于upstream/project上的合并提交。
当你的pull请求被接受时，分支被合并并且在upstream/project上进行提交，但是fork/project在你从上游再次提取之前并没有意识到这一点。
当你拉动时，fork/project首先获取新的提交，然后只需快进而不需要合并。只有这样，两棵树都是相同的。
关于策略：
非常广泛的情况是，由于所有的合并提交，合并策略（这里讨论）在树结构方面更嘈杂，更有点笨拙。另一方面，rebase策略更精简但也更棘手，如果人们不小心使用它，就会出现令人讨厌的情况。
为了进一步研究“战略”部分，已经有很多与优秀答案的比较，只是按照“合并/反思辩论”的方式进行搜索。