应将第一行保留pick，后续需合并的行改为squash（或s），因squash必须作用于前一个pick提交；保存后在新编辑器中精简提交信息。
git rebase -i 后怎么选 pick/squash
想把开发分支上连续的多次提交压成一个，git rebase -i 是最直接的办法。关键不是记命令，而是理解交互式 rebase 里每一行的操作含义。
运行 git rebase -i HEAD~n（n 是你要合并的提交数）后，编辑器会列出最近 n 条提交，每行开头默认是 pick。要把它们合成一个，只需把除第一条外的所有 pick 改成 squash（或简写 s）。
- 第一行必须保留
pick，它决定最终提交的 commit message 框架 - 后续行改成
squash后，Git 会把它们的内容和变更一并合并进第一个提交 - 保存退出后，会弹出另一个编辑器让你编辑最终的 commit message —— 这里可以删掉不需要的注释行，只留清晰的一句话描述
合并非连续提交时不能用 squash
如果想合并的提交中间夹着别人推送的提交、或者有 merge 提交，git rebase -i 就不安全了。强行操作可能丢变更、搞乱历史，尤其在共享分支上。
这时更稳妥的做法是先用 git checkout -b temp-branch 切到目标基线（比如 main），再把需要的变更 cherry-pick 过来：
- 用
git log --oneline feature-branch找出要合并的几个commit hash - 逐个执行
git cherry-pick <hash></hash>（注意顺序，避免冲突） - 全部应用完后，用
git reset --soft HEAD~n（n是 cherry-pick 的次数）把它们暂存为一次修改，再git commit
push 时遇到 rejected 怎么办
rebase 后 commit hash 全变了，如果原分支已推送到远程，直接 git push 会被拒绝 —— Git 在保护你别覆盖他人工作。
确认无误后，只能强制推送：git push --force-with-lease origin feature-branch。重点是用 --force-with-lease 而不是 --force：
-
--force-with-lease会检查远程分支是否有人在你 rebase 期间又推送过，有则中止，避免误覆盖 - 如果团队协作频繁，务必先沟通，确保没人正在基于你的旧分支开发
- 某些仓库禁止 force-push，这时就得走 merge request + “Squash and merge” 流程（GitHub/GitLab 界面按钮）
为什么不用 git merge --squash
git merge --squash 看似也能“合多为一”，但它本质是把另一分支所有变更变成**当前分支的一次新提交**，不保留原始提交记录，也不建立 merge 关系。
适用场景很窄：
- 临时集成测试分支，不想带历史进来
- 从别人 fork 的 PR 里提取功能，但不想继承其混乱提交
- 它不会改你当前分支的 HEAD 历史，所以 push 时不会被拒绝，也不用 force
但如果你原本就在自己的 feature 分支上工作，又想清理本地提交粒度，rebase -i 更精准——它改的是你自己的历史，且保留 author 信息和时间戳。
真正容易被忽略的，是 rebase 后每个 commit 的 author 和 committer 时间都会重置（除非加 --no-edit 或手动修正），CI 构建记录可能因此断连；还有，如果有 submodule 更新或大型二进制文件，squash 后的单次提交体积会陡增，影响 clone 速度。
