git 在当前分支是目标分支的直接祖先时自动触发 fast-forward merge，即指针前移不产生新提交；典型场景为从 main 拉出 feature 后 main 无新提交，再执行 git merge feature 即走 ff。
什么时候会自动触发 fast-forward merge
Git 在当前分支是目标分支的直接祖先时，自动执行 fast-forward 合并——也就是指针直接前移，不产生新提交。典型场景是：你从 main 拉出 feature，main 期间没任何新提交，再切回 main 执行 git merge feature，就走 FF。
容易踩的坑：
- 误以为 FF 是“没合并”，其实已生效，只是没 merge commit；
- CI/CD 流水线依赖 merge commit 触发构建，FF 合并会导致构建跳过；
-
git merge --ff-only feature失败时别硬切回--no-ff，先确认是否真要丢弃分支开发痕迹。
为什么 --no-ff 是团队协作的默认选择
git merge --no-ff feature 强制生成 merge commit，哪怕能 FF 也创建一个带两个 parent 的提交。它不是为了“好看”，而是解决可追溯性问题。
关键作用：
- 明确标记功能边界：
M提交的 message 可写 “Merge feature/login”，比一堆零散提交更易定位整块功能； - 支持原子回退：用
git revert -m 1 <merge-commit></merge-commit>可精准撤回整个分支，而不是手动挑 commit； - 避免“文件消失”陷阱：如
dev分支曾添加http.js又被 revert，后续再合并时 Git 会基于三路 base 判定该文件应被删掉——有 merge commit 才能看清这个决策链。
squash merge 适合什么情况
git merge --squash feature 不保留原分支的多次提交，把所有变更打包成一个新 commit，再由你手动 git commit。它本质是“变基式集成”，但不重写历史。
适用场景很具体：
- PR/ MR 审阅通过后，希望主干只留一条语义清晰的记录，比如
"feat: add password reset flow"； - 临时实验分支（如
spike/api-v2）验证可行，但提交过程杂乱（调试、回滚、print），不值得保留在主干历史里； - 外包或实习生提交的分支，需统一 author 和 message 格式。
注意：--squash 后必须手动 git commit，否则工作区变更还在，但 HEAD 没动——容易误以为“已经合并完了”。
三方合并（three-way merge）不是选项，而是 fallback
只要两个分支都从共同祖先出发后各自有提交，Git 就自动启用三方合并，不需要加参数。它用三个 commit 做对比：base + ours + theirs。
真正要关注的是冲突处理逻辑：
- 冲突标记（
/ <code>=======/>>>> feature）只是提示，不是最终结果； -
git status显示both modified的文件才需人工介入，其余 Git 已静默合入； - 不要在冲突中直接删掉别人的代码段——先理解 base 是什么，再决定保留哪边逻辑，或合成新实现。
复杂点在于：merge base 不一定是你肉眼看到的“最近共同提交”。Git 会选最优公共祖先（lowest common ancestor），有时是几周前的老提交。这就是为什么“明明刚拉的分支，一合并就冲突”的根本原因。
