git merge跳过某些提交是因为它只合并从两个分支最近共同祖先（merge-base）出发、在源分支有而目标分支没有的提交，而非简单追加所有源分支提交；若部分提交已存在或内容重复，则自动跳过。
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 消失的问题）。
- 不要手动指定
-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 并手动保留
多人长期并行开发，如何避免合并时爆炸式冲突？
核心不是“怎么合”，而是“什么时候合、合多少”。Git 的三路合并能力再强，也扛不住半年没同步的两个大分支。频繁小步合并比一次大合并更可靠，因为每次只比对少量变更，基础版本更近，冲突区域更局部。
- 强制约定：每个特性分支每周至少执行一次
git merge main（或git rebase main），保持与主干同步 - 避免“全量合并”：不要等所有功能做完才合，拆成逻辑闭环的小块（如“API 接口 + 对应测试”），逐个合并
- 用
git diff main...feature（三点语法）代替main..feature，它基于共同祖先而非单向历史，更能反映真实差异 - CI 流水线里加一步：
git merge --no-commit --no-ff main预检，失败即阻断 PR，不等到人肉合并才发现问题
真正麻烦的从来不是冲突标记本身，而是那些没被标记出来的“静默丢失”——比如文件消失、逻辑覆盖、配置项被覆盖。看清 merge-base 是谁、确认三方状态是否符合预期，比熟记命令重要得多。
