为何Git无法在两个远程仓库间执行Fast forward（快进）合并？

先给你把这个事儿说透：你遇到的这个快进合并，完全是Git在特定场景下的最优选择，咱一步步拆解：

为什么会触发快进合并？ #

Git会触发快进合并的核心条件只有一个：你要合并的分支（比如你加了提交E的分支）的提交历史，是目标分支（比如你的本地主分支）的直接延续。对应你的场景就是：本地主分支停在提交D，而你的开发分支的最新提交E的父节点正好是D，主分支在你做E的过程中完全没有新提交——这种情况下，Git觉得没必要搞复杂的合并操作，直接移动分支指针就够了。

快进合并到底做了什么？ #

和普通合并会生成新的合并提交不同，快进合并本质上就是移动目标分支的HEAD指针：

• 原本你的主分支HEAD指向提交D，开发分支指向E；
• 合并后，主分支的HEAD直接跳到E的位置，不会产生任何新的提交；
• 整个过程就像把主分支“快进”到了开发分支的最新状态，这也是它名字的由来。

实操中的相关命令 #

举个具体的命令流程，对应你的场景：

1. 假设你在开发分支feature上完成了提交E：

   git checkout feature
   # 做完修改后提交
   git add .
   git commit -m "Add commit E"
   

2. 切回主分支执行合并：

   git checkout main
   git merge feature
   

   这时候你会看到Git输出类似这样的内容：

   Updating a1b2c3d..x7y8z90
   Fast-forward
   file1.txt | 2 ++
   1 file changed, 2 insertions(+)

3. 如果你不想用快进合并（比如希望保留分支合并的明确历史），可以强制生成合并提交：

   git merge --no-ff feature
   

   这样Git会创建一个新的合并提交，把主分支和开发分支的历史明确关联起来。

结合你远程仓库的场景补充 #

你的myremote仓库比upstream多了提交E，当你在本地把这个包含E的分支合并回主分支时，因为主分支完全没有新的提交，快进合并是最简洁高效的方式——既不会产生多余的提交，也能让主分支的历史保持线性清晰。

内容的提问来源于stack exchange，提问作者markzzz