git rebase
是什么
git rebase = “把当前分支整个搬家，插到另一条分支的最新提交后面”，让历史看起来是一条直线，没有分叉。
图解
初始状态（feature 从 master 的 B 开出，又多了 C、D；master 那边又走了 E、F）：
复制
A—B—E—F ← master
C—D ← feature
merge 的效果（保留分叉）：
复制
A—B—E—F—M ← master
\ /
C—D ← feature
rebase 的效果（把 C、D 整体“剪下来”，贴到 F 后面，并生成全新 C’、D’）：
复制
A—B—E—F—C’—D’ ← feature
↑
历史成一条线，没有 merge 提交
常用场景
本地 feature 分支落后主分支，想同步最新代码又不要 merge 提交：
复制
git checkout feature
git rebase master
整理脏提交：
git rebase -i HEAD~3 # 合并/改消息/删除，见上文
合并 PR/MR 时保持主分支线性历史（GitHub 的 “Rebase and merge” 按钮）。
代价 & 注意
改写历史：rebase 后提交的 hash 全变，已 push 过的分支必须强推 (–force-with-lease)。
多人协作时，强推会扰乱同事，不要在公共分支上 rebase；只在自己尚未共享的 feature 分支上玩。
口诀
“rebase 是搬家，merge 是搭桥；搬家改门牌，搭桥留路口。”
具体好处
历史“无分叉”
merge 会留下一个“合并提交”（merge commit），多分支并行久了就成了“铁路图”；
rebase 把分支“搬家”后，看上去像顺序开发，review 时一眼到底。
代码 review 更轻松
GitHub/GitLab 的 PR/MR 界面里，线性历史能让改动按真正时间顺序排列，不会穿插大量“Merge branch ‘master’ into xxx”噪音。
回退、bisect 更方便
git bisect 二分查找 bug 时，线性历史每次编译点都是可运行状态；merge 提交点常常编译不过，增加排查成本。
可以“整理脏提交”
git rebase -i 让你把“WIP”、“fix typo”、“oops” 压缩成一条优雅提交，再合并进主分支，保持主库提交都是“一个 feature 一条记录”。
避免无意义的合并冲突
先 rebase master 再提 PR，能把冲突在本地一次性解决，而不是等合并时让 CI/同事踩坑。
代价与边界
改写历史，必须强推；公共分支上严禁 rebase（会踩到同事）。
一旦 rebase 完，旧提交的 hash 全部失效，引用旧 hash 的文档、issue 会断链。
口诀
“私有分支随意搬家，公共分支只搭桥不搬家。”
这就是 rebase 存在的理由：让“对外历史”整洁，让“对内开发”灵活。
demo ——修改当前分支提交历史
首先备份一份最新的版本 放到其他目录 防止改崩
git rebase -i HEAD~10
然后会进入vim
pick a1b2c3 第一个提交信息 pick d4e5f6 第二个提交信息 pick g7h8i9 第三个提交信息只保留第一条 其他最前面全部改成squash
pick a1b2c3 第一个提交信息 squash d4e5f6 第二个提交信息 squash g7h8i9 第三个提交信息然后！wq保存
之后看提示 关注source状态 可能编辑提交信息
之后确认即可
然后就发现 当前分支变成只有一个提交记录了
之后强推即可
过程中间会一个游离分支
如果一半不想改了 也可以取消