应使用 git merge --squash 当无需保留功能分支中间提交、主分支需保持简洁可读历史时，典型场景包括短期修复、ui微调或ci要求单语义化提交；执行后需手动 commit，且原始作者信息丢失但可通过pr追溯。
什么时候该用 git merge --squash？
当你明确不需要保留功能分支的中间提交细节，且主分支（如 main）只承担“可发布、可回溯、可阅读”的职责时，git merge --squash 就是合理选择。典型场景包括：短期修复分支（hotfix/login-validation）、UI微调分支（含大量 fix: adjust padding 提交）、或 CI/CD 流水线要求每次合并只产生一个语义化提交。
它不是“偷懒”，而是主动放弃过程记录，换取主线历史的可读性。但前提是团队已建立配套机制——比如所有 PR 都关联 Jira 单或 GitHub Issue，原始提交信息能通过链接追溯。
- 别在长期活跃的功能分支上直接用
git merge --squash，否则会丢失迭代逻辑 - 如果分支里混了多个不相关改动（比如同时改了登录和支付），先本地拆分再 squash，否则一个提交塞进两件事，commit message 很难写清楚
- CI 自动构建失败后，不要直接
git commit -m "fix ci"再 squash —— 这会让最终提交里包含调试残留，应先git diff --cached确认变更范围
git merge --squash 之后为什么不能直接 push？
因为 git merge --squash 只把变更暂存到 index（即 staging area），不会自动创建 commit。它本质上是“把别人分支的所有改动，当成你本地未提交的修改来对待”。所以必须手动 git commit 才算完成。
这个设计其实很关键：它强制你在提交前检查内容。我见过太多人漏掉这步，结果 git status 显示 “nothing to commit”，误以为合并已完成，实际代码根本没进主分支。
- 执行完
git merge --squash feature/auth后，立刻运行git diff --cached，确认只有预期文件被修改 - commit message 别写 “squash merge”，要用功能语义，比如
feat: add JWT token refresh on 401 - 如果发现意外引入了
console.log或临时注释，现在就是清理的最佳时机，而不是等 QA 发现再回滚
作者信息丢失是 bug 还是 feature？
是 feature，但得接受它的代价。Squash 后的提交 author 是执行 git commit 的人，committer 是当前用户，原始提交里的多作者信息全部消失。这对开源项目或跨团队协作可能构成追溯障碍。
但如果你的流程中，PR 审阅者和最终合并者都是同一角色（比如 Tech Lead），且所有开发行为都绑定到 Issue/PR 页面，那作者信息就只是辅助项，不是唯一信源。
- 别指望靠 git blame 查某个变量是谁加的——要查，得去对应 PR 的 commits tab 里翻原始记录
- 如果公司审计要求“每行代码可追溯到具体开发者”，Squash Merge 不满足合规要求，得换 Rebase 或常规 Merge
- GitHub/GitLab 的 PR 页面默认保留 squash 前的所有 commit hash，只要不删 PR，原始作者信息就没丢，只是不在
git log里直出
和 rebase -i 比，Squash Merge 真的更简单吗？
表面上更简单，实则隐藏复杂度。Squash 是“一键压缩+手动提交”，Rebase 是“交互式重排+可能冲突+多次 amend”。但真正麻烦的是后续影响：
Squash 后，功能分支的原始提交彻底与主分支历史断开，如果有人基于那个分支继续开发（比如 feature/auth 上又切了 feature/auth-2fa），再想同步主线更新，就得重新 git rebase main，而不是简单 git merge main —— 因为原分支的 base 已被“抹平”。
- 团队若采用 Squash Merge，建议所有功能分支都从最新
main拉取，避免嵌套依赖 - 不要对已 squash 合并过的分支执行
git push --force，否则远程分支的提交对象和本地不一致，别人git pull会出错 - CI 脚本里如果依赖
git log -n 1 --oneline解析当前版本，注意 squash 提交的 message 是人工写的，不是自动生成的，需确保格式统一
