交互式 rebase 仅适用于未推送的本地提交：✅ 个人功能分支合入前清理、修复未推送的错误；❌ 禁止用于已推送到 main/develop 或多人协作的长期分支。
git rebase -i 什么时候该用，什么时候不该用
交互式 rebase 是本地历史编辑工具，不是合并手段。它只适合尚未推送到共享远程分支的提交——一旦 git push 过，再 git rebase -i 就等于重写他人可能已基于的历史，后续必须 git push --force-with-lease，且得提前同步团队。
- ✅ 适用场景：个人功能分支（如
feature/login）在合入前清理 - ✅ 适用场景：修复自己刚提交但还没推送的拼写错误、拆分过大提交
- ❌ 禁止场景：已
git push到main或develop的提交 - ❌ 禁止场景：多人协作的长期存活分支（如
release/2.3）上直接操作
rebase -i 编辑器里那些指令的实际效果
打开 git rebase -i HEAD~4 后，编辑器中每行开头的动词决定该提交的命运。别只记名字，要看它改了什么：
-
pick：原样保留，哈希值不变（仅当未被 rebase 过） -
reword：停在该步，让你用git commit --amend改消息，不碰代码 -
squash：合并到前一个pick提交，保留两个消息供你编辑整合 -
fixup：同样合并，但自动丢弃本条消息，只留前一条的标题 -
edit：暂停，允许你git reset HEAD~、git add -p、git commit重新构造提交内容
注意：squash 和 fixup 只对紧邻的前一个 pick 生效；如果中间夹了 reword，它们会失效。
解决 rebase 过程中出现的冲突
冲突不是失败，是 rebase 正常工作的信号——说明某次“重演”时，Git 不确定如何把你的旧变更应用到新基线上。
- 手动编辑冲突文件，删掉
/ <code>=======/>>>>>标记，保留正确逻辑 - 改完后必须
git add <file></file>—— 没这步，git rebase --continue会报错 - 如果卡住想放弃，用
git rebase --abort，一切回到 rebase 前状态 - 不要用
git merge解冲突，那会破坏 rebase 的线性目标
强制推送前必须确认的三件事
git push --force-with-lease 看似安全，但仍有风险。执行前务必核对：
- 远程分支是否已被他人更新？
git fetch origin && git log origin/main..main应为空 - 你正在推送的分支是否只有你自己在用？查
git branch -r有无他人 tracking 分支 - 有没有 CI/CD 流水线依赖旧提交哈希？比如某些部署脚本硬编码了
commit-id
最容易被忽略的是：rebase 后所有提交哈希都变了，GitHub/GitLab 上原有的 PR 评论、CI 构建记录、issue 关联都会断开——这不是 bug，是设计使然。
