rebase会重写提交哈希，切勿在已推送的分支上使用；它将提交序列挪至新基底重放，改变所有新提交哈希，破坏协作历史，仅限本地未共享分支操作。
rebase 会重写提交哈希，别在已推送的分支上乱用
Git rebase 不是“合并”，而是把一串提交“挪”到另一个基底上重放，所有新生成的提交哈希都会变。这意味着：如果你已经 git push 过原分支，别人基于它工作过，你再 rebase 后强制推送（git push --force-with-lease），就会破坏协作历史。
- 只对本地未共享的分支做
rebase—— 比如你刚从main拉出的feature/login，还没push过 - 团队约定不
rebase公共分支（如main、develop）是铁律，不是建议 -
git pull --rebase默认行为安全，因为它只 rebase 你本地新增的提交，不碰上游已存在提交
交互式变基（rebase -i）怎么精简/拆分/修正提交
想把 5 个杂乱提交压成 2 个语义清晰的提交？或者把一个大提交按功能拆开？git rebase -i HEAD~5 是唯一靠谱方式。关键不是记命令，而是理解编辑器里每行操作词的含义：
-
pick：保留该提交（默认），顺序决定最终提交顺序 -
squash（或s）：和前一个pick合并，会进编辑器让你改 commit message -
fixup（或f）：和前一个pick合并，但直接丢弃当前 message，适合修 typo 或小补丁 -
edit（或e）：停在这步，可git commit --amend改内容或 message，改完要git rebase --continue
常见翻车点：rebase -i 中误删某行 → 那个提交彻底消失；保存前没检查顺序 → 提交逻辑错乱；中途改错又 --abort 太晚，已污染暂存区。
rebase vs merge：什么场景必须用 rebase
不是“哪个更好”，而是“哪个不破坏当前工作流”。真实项目里，rebase 的不可替代场景其实很窄：
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 向主干贡献 PR 前，清理个人分支历史：比如把 “wip”、“fix ci”、“oops typo” 这类提交压缩掉，让 reviewer 看到干净逻辑流
- 同步
main最新改动时避免无意义的 merge commit：用git checkout feature && git rebase main替代git merge main，保持线性历史 - 调试时定位引入 bug 的提交：配合
git bisect，非线性历史会让二分失效，rebase整理后更可靠
注意：rebase 不解决冲突本身，只是把冲突时机提前到变基过程中，而且每个被重放的提交都可能触发一次冲突，比一次 merge 冲突更碎、更烦。
rebase 失败后如何安全回退
执行 rebase 卡住、冲突没解完就关了终端、或者手抖 --skip 错了提交……别硬扛。Git 给了明确逃生通道：
- 还在变基中？直接
git rebase --abort，一切回到rebase前状态（包括未提交修改） - 已经
--continue出错了，但还没推？查git reflog找到rebase前的 HEAD，用git reset --hard HEAD@{1}回滚（HEAD@{1}是示例，实际看 reflog 输出） - 不小心推了 force？立刻通知协作者，让他们用
git fetch origin && git reset --hard origin/branch-name强制同步（仅限小范围、未多人基于该分支开发）
最易忽略的一点：rebase 过程中 Git 会在 .git/rebase-apply/ 或 .git/rebase-merge/ 留下痕迹，这些目录没清空，下次 rebase 可能报错或行为异常 —— --abort 会自动清理，手动中断则得自己删。
