什么时候该用 git rebase 而不是 git merge
rebase 用于：同步主干到个人功能分支（线性历史）、合并前整理提交（squash 杂乱 WIP）、搬运提交串。merge 用于：共享分支合并、需要保留真实合并记录的场景。铁律：已推送且有人使用的历史不 rebase。
简单口诀：自己的提交整理用 rebase，别人的历史汇合用 merge。 rebase 得到线性干净的历史但改写提交；merge 保留真实拓扑但多出合并节点。
该用 rebase 的场景
- 功能分支同步主干：
git rebase main——你的提交像是一直基于最新代码写的，历史一条线； - 合并前整理：
git rebase -i把 "fix typo"、"wip" 之类的杂乱提交 squash 干净再合 PR； - 搬运提交串：
git rebase --onto把分支嫁接到另一个基点。
该用 merge 的场景
- 共享分支的汇合：main/release 上的合并——历史真实可审计；
- 需要"这个特性是整体进来的"语义：合并提交本身就是边界标记（--no-ff）；
- 长期并行分支：反复 rebase 长分支会不断重写，冲突反复出现，merge 只解一次。
黄金法则
已推送并被他人使用（或可能使用）的提交，不要 rebase。
rebase 改写哈希，别人基于旧历史的工作会全部错位。个人分支、未推送的提交随便 rebase；公共历史只进不退（merge/revert）。
常见问题（FAQ）
Q：pull 时用 rebase 还是 merge？
个人习惯 + 团队约定。pull.rebase=true 让你本地的零星提交不产生无意义合并节点，多数团队推荐。
Q：rebase 的"线性历史"有什么实际好处？
git bisect 二分定位 bug 更顺、git log 更易读、 revert 单个特性更干净。历史是给未来的自己看的文档。
Q：两者能混用吗？
日常就是混用的：功能分支上 rebase 整理，合回 main 用 merge（或 squash）。关键是别对共享历史 rebase。
