--first-parent 仅沿每个合并提交的第一个父提交追溯历史，跳过被合入分支的全部提交，从而呈现以目标分支（如 main）为主线的简化拓扑，适用于严格 Git Flow 的 merge --no-ff 场景。
什么是 --first-parent，它到底过滤了什么
Git 的 git log 默认会展开所有父提交，包括 merge 提交的多个分支来源。这会让历史看起来“发散”，尤其在频繁 merge 的项目里，主线（比如 main）被大量 feature 分支的提交穿插其中。--first-parent 不是“只显示当前分支”，而是**强制只跟随每个 merge 提交的 *第一个* 父提交**——也就是被 merge 进来的那个分支（通常是目标分支），跳过被合入的源分支历史。
典型场景：你在 main 上执行 git merge feature/login，这个 merge 提交有两个父：第一个是 main 上的前一个 commit，第二个是 feature/login 分支 tip。加 --first-parent 后，log 就只连回 main 的上一个 commit，完全跳过 feature/login 分支内部的全部提交。
怎么用才真正简化主线，而不是漏掉关键信息
直接 git log --first-parent 很容易误以为“主线干净了”，但实际可能掩盖问题。它只适合明确以 merge 为交付单元的流程（例如 Git Flow）。如果团队习惯用 rebase 或 merge --squash，--first-parent 反而会把 squash 后的单个提交也当成 merge 提交处理，导致跳过本该保留的逻辑。
- ✅ 推荐搭配
--oneline --graph使用：git log --first-parent --oneline --graph，能一眼看出主线骨架和 merge 点 - ✅ 想看某个 merge 提交的完整上下文？先用
--first-parent定位到该 merge，再单独查它：git show <merge-commit-hash>或git log -p --no-merges <merge-commit-hash>^2（查被合入分支） - ❌ 别用
--first-parent替代--no-merges：后者只是隐藏 merge 提交本身，前者是改变拓扑遍历路径
--first-parent 对 bisect 和 blame 的影响
这是最容易踩坑的地方：git bisect 和 git blame 默认不认 --first-parent，它们仍按完整 DAG 遍历。所以你用 --first-parent 看着“干净”的历史去定位 bug，实际 bisect 可能落在被跳过的 feature 分支提交上。
如果你依赖 --first-parent 定义“主线”，就得配套约束工作流：
- 所有功能交付必须通过
git merge --no-ff（确保有 merge 提交） - 禁止在
main上rebase或cherry-pick，否则--first-parent路径会断裂或指向错误提交 -
git bisect前先确认测试范围是否真在 first-parent 链上，必要时加--first-parent参数（git bisect start --first-parent）
替代方案：什么时候该放弃 --first-parent
当团队混合使用 merge、rebase、squash，或者 CI/CD 流水线自动创建 merge 提交（如 GitHub PR 的 “Merge commit”），--first-parent 会变得不可靠——它无法区分“人工 merge”和“自动化 merge”，也无法识别 rebase 后的线性历史。
更稳健的做法是：
- 用
git log --oneline --simplify-by-decoration：只显示带 tag/branch ref 的提交，视觉上聚焦关键节点 - 配合
git log main --not feature/*手动排除已知 feature 分支 - 用
git log --author="CI Bot"过滤掉自动化提交，比依赖 merge 结构更可控
真正决定历史可读性的，不是参数本身，而是团队对 merge 行为的一致约定。参数只是放大器，不是修正器。
