git rebase本质是重写历史，用新提交替代旧提交以实现线性历史；适用于本地未推送分支的整理或pr前清理，但严禁在已共享分支上使用，否则破坏他人本地历史。
git rebase 是实现多分支历史“变单线”的核心手段，但它不是无脑压平——它重写提交哈希、改写父提交指针，本质是**用新提交替代旧提交**。直接 git merge 会产生 merge commit，天然带分叉；而想让历史看起来像一条直线，必须用 rebase，但得清楚代价。
什么时候该用 git rebase 而不是 git merge
你明确希望目标分支（比如 feature）的所有提交，按时间顺序“叠”在当前主干（比如 main）最新提交之后，且不留下 merge 提交节点。典型场景包括：
- 本地功能分支尚未推送到远程，且你愿意承担重写历史的风险
- PR 前清理提交记录（如 squash 多个调试提交为一个语义清晰的提交）
- 团队约定：所有 PR 必须基于最新
main，且提交历史线性可读
反例：分支已推送到远程并被他人基于它继续开发——此时 rebase 会破坏他人本地历史，引发混乱。
git rebase -i 的关键操作和常见陷阱
交互式变基是控制“单线化”粒度的核心。执行 git rebase -i main 后会打开编辑器，每行代表一个待处理提交，前面的命令决定其行为：
-
pick：保留该提交（默认），位置可上下拖动调整顺序 -
squash或s：与前一个pick合并，丢弃本次提交信息，仅保留变更 -
fixup或f：同squash，但直接丢弃本次提交信息，不进编辑器 -
drop：彻底删除该提交（慎用，尤其含重要变更时）
容易踩的坑：
- 误删
pick行首单词（如写成pic），会导致整个 rebase 中断并报错Unknown command: pic - 对已推送的提交执行
rebase后强制推送（git push --force-with-lease），若别人在此期间也推了新提交，你的强制推送会覆盖掉他们的工作 - 在
squash后保存退出时，编辑器未正确关闭（如 vim 忘记:wq），导致 rebase 卡住，后续所有 git 操作都会提示 “rebase in progress”
合并后如何验证历史是否真“单线”
别只信 git log --oneline 的视觉效果。真正判断是否单线，要看每个提交的父提交数量：
- 线性提交：每个提交都只有 1 个父提交（
git show --pretty=%p HEAD~2输出应为单个 SHA） - merge 提交：输出为两个 SHA，形如
a1b2c3d e4f5g6h - rebase 后的提交：哈希值全变了，且每个都只指向它“前一个”新提交，而非原始父提交
更可靠的方式是跑：git log --merges --oneline —— 如果没有任何输出，说明当前分支确实没有 merge commit；再配合 git log --graph --oneline --all 看图谱，确认无分叉线。
为什么不能总靠 rebase 解决协作问题
单线历史好看，但掩盖了真实的协作时序。比如：
- A 在
feature-A上开发，B 在feature-B上开发，两人同时基于旧版main工作 → 各自 rebase 到最新main后，谁先 push 谁的 rebase 成功，后 push 的人必须再次 pull + rebase，形成“重写竞赛” - 某次 bug 修复实际发生在
hotfix分支，但 rebase 到main后，这个修复“看起来”像是直接在main上做的，丢失了上下文 - CI/CD 流水线依赖提交哈希做构建缓存或部署标记，rebase 后哈希全变，缓存失效，部署链断裂
真正的工程权衡不在“要不要单线”，而在“谁负责维护这条线”——是个人本地清理，还是由 CI 自动做 rebase --ff-only + merge 组合策略。强行统一单线，往往比接受合理分叉更费维护成本。
