用 git rebase -i 合并本地未推送的提交最稳妥；若已推送到远程，且他人未基于这些提交继续开发，可配合 git push -f 强制推送，但必须提前沟通。
直接说结论：用 git rebase -i 合并本地未推送的提交最稳妥；若已推送到远程，且他人未基于这些提交继续开发，可配合 git push -f 强制推送，但必须提前沟通。
怎么用 git rebase -i 合并最近 N 个提交
这是最常用、控制粒度最细的方式，适合整理自己分支上连续的开发提交。
- 先确认要合并的提交范围：运行
git log --oneline -n 5查看最近 5 条，找到最早那个「不想动」的提交哈希（比如p3q4r5s），然后执行：git rebase -i p3q4r5s - 编辑器打开后，把除第一行外的
pick全部改成s（squash）或f（fixup，不保留原提交信息） - 保存退出后，会再弹出一个编辑器，让你写最终的提交信息。注意：删掉所有以
#开头的注释行，只留一条清晰的描述，比如feat: 登录功能完整实现 - 如果中途改错退出了，可用
git rebase --abort回退到操作前状态
为什么不能对已推送的提交随便 rebase
因为 rebase 本质是「重放」提交——它会为每个被 squash 的提交生成新哈希。一旦原始提交已推送到远程，别人再 git pull 就会看到重复、分叉甚至冲突的历史。
- 典型报错：
error: Your local changes would be overwritten by merge或拉取后出现重复 commit - 协作前提：仅限于你自己的 feature 分支，且确认没人
git checkout过这些提交、也没人基于它们开新分支 - 如果已推送，强制推送前务必通知协作者，并确保他们先备份本地修改，再用
git fetch && git reset --hard origin/your-branch重置
git merge --squash 和 rebase -i 的关键区别
两者都能得到「一个提交」，但适用场景完全不同。
-
git merge --squash feature-branch是把feature-branch的所有变更暂存起来，不带历史地合入当前分支，之后需手动git commit。适合「把别人分支的部分改动收进来，但不想引入对方历史」 -
git rebase -i是在当前分支内部整理自己的提交链，目标是让历史线性干净。它不涉及跨分支逻辑，也不改变文件内容，只改提交元数据 - 性能影响：两者都不影响工作区文件，但
rebase -i在提交多时可能触发多次冲突解决；merge --squash只解决一次冲突（如果有的话） - 兼容性：
merge --squash安全，可随时撤回（没commit前git reset即可）；rebase -i一旦完成，旧提交就从 reflog 里快速淡出，恢复成本高
真正容易被忽略的点是：合并不是目的，可追溯才是。过度压缩（比如把 10 个语义明确的提交压成 1 个）反而会让 Code Review 和 bisect 定位失效。建议保留「功能边界清晰」的粒度，比如一个接口 + 对应测试 + 文档更新算一组，而不是按时间堆砌。
