是什么
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
bash
pick a1b2c3 第一个提交信息
pick d4e5f6 第二个提交信息
pick g7h8i9 第三个提交信息只保留第一条 其他最前面全部改成squash
bash
pick a1b2c3 第一个提交信息
squash d4e5f6 第二个提交信息
squash g7h8i9 第三个提交信息然后！wq保存
之后看提示 关注source状态 可能编辑提交信息
之后确认即可
然后就发现 当前分支变成只有一个提交记录了
之后强推即可
过程中间会一个游离分支
如果一半不想改了 也可以取消