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