一文读懂Git分支分叉后的多路径合并处理（复杂场景）-git-PHP中文网

git merge跳过某些提交是因为它只合并从两个分支最近共同祖先（merge-base）出发、在源分支有而目标分支没有的提交，而非简单追加所有源分支提交；若部分提交已存在或内容重复，则自动跳过。

一文读懂git分支分叉后的多路径合并处理（复杂场景）

git merge 为什么跳过某些提交？

Git 不会简单地把“源分支所有提交”一股脑塞进目标分支。它真正做的是：找出两个分支的最近共同祖先（merge-base），然后只合并从那个祖先出发、在源分支上有、但在目标分支上没有的提交。如果你之前已经合并过部分提交，或者目标分支后来又自己追加了相同内容，git merge 就会跳过它们——不是漏了，是判定“没必要再合一次”。

常见现象：Already up to date 提示，但你明明看到源分支有新 commit；或者 git log --oneline feature 显示一堆提交，git merge feature 却只生成一个空合并提交。

用 git merge-base main feature 确认实际参考点，别只看分支名
用 git log --cherry-pick main..feature 查看哪些提交真正在 feature 上、却没出现在 main 中（这才是 merge 实际要拉的内容）
如果参考点太老（比如几个月前），git merge 可能因大量冲突放弃自动合并，转而要求你手动干预

三方合并失败时，git merge -s resolve 和 -s recursive 有什么区别？

git merge 默认用 -s recursive，它支持递归查找多个共同祖先，并尝试构建“虚拟基础”来缓解复杂分叉。而 -s resolve 是更保守的策略：只找一个共同祖先，不递归，一旦遇到多于一个候选 merge-base，就直接报错或退化为手动选择。

典型场景：A 分支从 main 分出 → B 分支从 A 分出 → B 合并回 main → A 再次尝试合并到 main。此时 main 和 A 之间存在多个合法 merge-base（原始 main 分叉点 + B 合并后的新点），recursive 会尝试融合两者，resolve 则可能卡住或选错基础，导致看似“无冲突”实则丢代码（如《这才是真正的 Git——分支合并》里 http.js 消失的问题）。

Gitlab Mr Review Pipeline

自动化 GitLab MR 代码审查流水线，利用 AI 生成审查报告并邮件发送给提交人。

下载

不要手动指定 -s resolve，除非你明确知道只有一个干净的共同祖先
-s recursive 是默认且推荐的，它才是处理长期分叉分支的主力
若 recursive 仍失败，可加 --no-commit 先预览变更，再 git status 检查是否意外删了文件

合并后文件凭空消失，但没报冲突

这不是 bug，是三路合并逻辑的必然结果。当某文件在共同祖先中存在，在目标分支（如 main）中被删除，而在源分支（如 feature）中未改动 —— Git 会认为“删除是目标分支的明确意图”，于是最终结果就是该文件不存在。哪怕你在 feature 分支里还引用着它，也不会触发冲突，因为“删”和“没动”不构成三方差异。

最典型的坑：一个分支 revert 了某个功能提交（含文件删除），另一个分支在此基础上继续开发并依赖该文件。合并时 Git 看到“祖先有、main删了、feature没动”，就直接删掉，不提示。

用 git show :0:filename、git show :1:filename、git show :2:filename 分别查看共同祖先、目标分支、源分支中该文件是否存在
预防方式：revert 后，立刻在 main 上补一个空 commit 或文档说明，避免后续分支误判“删除是永久决定”
补救方式：先 git merge --abort，再 git checkout main -- filename 恢复文件，然后重新 merge 并手动保留