结论：应避免直接用 git merge 合入主干，尤其当 feature 分支含大量低质量 commit 时；推荐用 git merge --squash 生成单条语义清晰的提交，或先 git rebase -i 清理再合并。
直接说结论：别用 git merge 直接合进主干，尤其当 feature 分支里一堆 fix typo、WIP、try again 这类 commit 时。默认合并会把它们全塞进主干历史，review 和 bisect 都会变困难。
为什么 git merge 会让主干变脏
默认 git merge 是“保留全部历史”的策略。它不关心你本地分支的 commit 质量，只管把所有提交节点连同 author、timestamp、message 一起拉进来。哪怕你写了 12 条 commit，其中 10 条是调试痕迹，主干也会原样收下。
- 主干
git log --oneline看起来像这样：abc1234 Merge branch 'feat/login'→ 下面紧跟着 12 行杂乱 commit -
git bisect可能停在某条fix indentation上，实际 bug 并不在那儿 - PR review 时 reviewer 得手动跳过 8 条无关 commit，效率极低
git merge --squash 是最稳妥的替代方案
它把整个分支的变更“打平”成一次工作区修改，不带任何 commit 元数据，由你手动生成一条干净的 commit。适合绝大多数内部协作场景。
- 执行前确保已在目标分支（如
main）：git checkout main - 运行：
git merge --squash feat/login - 此时变更已暂存，但没 commit：
git status显示 modified files in red，staged in green - 写一条语义清晰的 message：
git commit -m "feat: add login with JWT auth and password reset flow" - 不会产生 merge commit，也不改变
feat/login分支本身
注意：--squash 后必须手动 git commit，否则什么都不会真正提交。
想保留分支结构？用 git rebase -i 清理后再 merge
如果你需要保留分支拓扑（比如团队要求每个功能对应一个 merge commit），那就先在 feature 分支上做交互式变基，再走普通 git merge。
- 切换到 feature 分支：
git checkout feat/login - 清理最近 5 次提交：
git rebase -i HEAD~5 - 编辑器里把不需要的 commit 行前的
pick改成s（squash）或f（fixup） - 保存退出后，Git 会合并 commit 并弹出编辑器让你重写最终 message
- 解决冲突（如有）后：
git rebase --continue - 最后回到
main执行git merge feat/login，此时只有一条有意义的 merge commit
警告：如果该分支已推送到远程且别人在用，rebase 后必须 git push -f，且要提前同步所有人——这是唯一容易引发协作混乱的环节。
已经推到远程了，还能救吗
能，但代价不同。关键看是否有人基于那些脏 commit 继续开发：
- 没人依赖：直接
git rebase -i清理 +git push -f - 有人正在基于它开发：别动远端历史，改用
git revert回滚掉无用 commit，再用--squash重新合一次 - 已经合进主干：只能接受现实，下次 PR 前强制本地清理；或者用
git filter-repo（高危操作，需全员重 clone）
最容易被忽略的一点：清理 commit 不是“删历史”，而是让每次提交真正承载一个可验证的逻辑单元。哪怕只改一行代码，只要它独立完成一个子任务（比如“修复 token 过期时 401 响应体为空”），就值得一条 commit；而连续三次 git commit -am "fix"，本质是同一意图的重复表达，必须合并。
