多分支并行的时候，提交历史很容易变得混乱：一条主干、三四条特性分支，还有临时拉出来修 bug 的 hotfix 分支，用git log --graph一看，合并线交织在一起。前阵子帮一个小组整理仓库，三条特性分支各自落后主干二三十个提交，负责人图省事挨个merge main，结果主干上多出六条合并记录，回滚定位问题时没人说得清哪次合并带进来了什么。后来我把这几条分支挨个用git rebase追平主干，历史重新变成一条干净的直线，每个提交对应一件事，git bisect十分钟就锁定了问题区间。这件事让我再次确认：多分支管理里，git rebase并不是可选项，使用得当就能显著改善仓库结构。这篇随笔聊聊我在实际项目里怎么使用它，包括它到底改了什么、冲突怎么处理、哪些情况下要避免使用，以及几个容易忽略但很关键的细节。
1. 多分支并行时，rebase 和 merge 的分工边界
1.1 一个典型的提交历史混乱现场
先还原一个常见场景。主干main上每天都有提交进来，你从两周前拉出的feature/order-export分支上做了 12 个提交，中间还穿插着别人合并进来的重构。这时候你想把主干的改动同步过来，有两个选择：
# 选择一：merge git checkout feature/order-export git merge main # 选择二：rebase git checkout feature/order-export git rebase main选 merge，你的分支上会多出一个合并提交，历史变成"分叉再汇合"的形状。一次两次无所谓，但如果这条分支活了三个月，你每周同步一次主干，那就是十几个合并提交，git log里全是Merge branch 'main' into feature/order-export这种信息量为零的记录。更麻烦的是，当你最终把这条分支合回主干时，主干上会留下一个巨大的合并节点，git blame追到那个节点就没法继续往下走了，因为它同时指向两条父提交链。
选 rebase，你的 12 个提交会被依次"搬"到主干最新提交之上，历史依旧是一条直线。代价是这 12 个提交的哈希全部变了，如果这条分支已经推送到远端并且有别人在基于它工作，那就得处理强制推送带来的连锁反应。
我的判断标准很直接：这条分支是不是只有我一个人在用。是，就 rebase；不是，就老老实实 merge，或者约定好同步窗口。
1.2 两种操作在语义上的根本区别
很多人把 merge 和 rebase 当成"两种合并方式"，其实它们解决的是不同问题。
| 维度 | merge | rebase |
|---|---|---|
| 历史形态 | 保留分叉，产生合并提交 | 拉成直线，无合并提交 |
| 提交哈希 | 原有提交不变 | 全部重新生成 |
| 冲突处理次数 | 一次合并解决一次 | 可能每个提交都要解一次 |
| 适用分支 | 共享分支、长期分支、发布分支 | 个人特性分支、本地临时分支 |
| 是否改写历史 | 否 | 是 |
| 事后追溯难度 | 合并节点处断裂 | 线性可追溯 |
关键在最后一行。git bisect、git blame、git log -S这些工具在线性历史上效率最高，一旦遇到合并节点，它们要么跳过要么需要额外参数。我在排查线上问题时最依赖git bisect run，它要求历史尽量线性，否则二分区间会被合并提交打乱。这也是我坚持在个人分支上 rebase 的核心理由：这不是审美问题，它直接影响事后排查的效率。
但反过来，共享分支绝对不能 rebase。主干、发布分支、多人协作的集成分支，只要有第二个人基于它提交过，改写历史就等于把别人的工作基础抽走。这条界限不能触碰。
2. rebase 的底层动作：提交到底被搬到了哪里
2.1 提交哈希为什么会变
理解 rebase 的关键是理解 Git 的提交对象结构。一个提交对象包含：树对象哈希（当前快照）、父提交哈希、作者信息、提交者信息、提交说明。这五项里任何一项变了，整个提交的 SHA-1 值就会变。
rebase 做的事，本质上是把你的每个提交"重新提交一遍"到新基底上。新基底不同，父提交哈希就不同，于是新提交的哈希必然不同。所以 rebase 之后git log里显示的哈希全变了，这不是 Git 出了问题，而是必然结果。
这也解释了一个常见困惑：rebase 之后git range-diff能对比出"内容一样但哈希不同"的两组提交。它的用法是这样：
# 对比 rebase 前后 feature 分支的差异 git range-diff main@{1}..feature@{1} main..feature输出里，如果某个提交标记为=，说明补丁内容完全一致只是换了基底；标记为!说明内容有变化（通常是你解冲突时改动过）。我在做大规模 rebase 之前会先记下feature的旧位置，rebase 完跑一次 range-diff，确认除了预期的冲突解决之外没有别的改动漏进去。这一步能挡掉不少"解冲突时手滑删了一行"的低级事故。
2.2--onto参数的三段式记忆法
git rebase --onto是这条命令里最容易被绕晕的部分，但它在多分支管理里恰恰最有用。语法是：
git rebase --onto <新基底> <旧基底> <要移动的分支>读法是：把<要移动的分支>上"从<旧基底>之后开始"的那一段提交，整体搬到<新基底>上。三个参数，从左到右对应"搬到哪、从哪切、搬谁"。
举个实际例子。你从main拉出feature/base，又从feature/base拉出feature/ui。现在发现feature/base里有个提交写错了，想把它从历史里剔掉，但feature/ui上的工作要保留：
# 把 feature/ui 上"feature/base 之后"的提交，搬到 main 上 git rebase --onto main feature/base feature/ui执行完，feature/ui就脱离了feature/base，直接挂在main后面。这个操作在拆分分支、调整依赖关系时非常顺手，比手动 cherry-pick 一串提交干净得多。
再补一个更省事的选项：从 Git 2.38 开始，git rebase支持--update-refs。它解决的是"分支栈"问题：A分支上叠着B，B上叠着C，你对A做 rebase 时，B和C的引用会自动跟着移动，不用手动逐个 reset。
git rebase --update-refs main我在做功能拆分时特别依赖这个开关，以前改完底层分支要手动把上面两层分支git reset --hard到新位置，现在一条命令搞定。也可以在配置里常开：
git config --global rebase.updateRefs true3. 把落后主干的分支追平：一次完整的交互式 rebase
3.1 动手之前的两个基本保障
我见过太多人 rebase 出问题后第一反应是"完了，代码没了"。实际上 Git 几乎不会真的丢东西，前提是你知道去哪里找。动手前做两件事就够了。
第一，记下当前分支的哈希：
git rev-parse feature/order-export # 输出类似 a1b2c3d4...把它抄在便签上或者粘到临时文件里。万一 rebase 之后发现不对劲，git reset --hard a1b2c3d4就回去了。
第二，理解reflog的作用。rebase 的每一步都会写进 reflog，包括rebase (start)、rebase (pick)、rebase (finish)这些标记：
git reflog show feature/order-export输出里能看到完整的操作轨迹。就算你不记得原始哈希，feature/order-export@{1}这种写法也能取到上一次的位置。另外ORIG_HEAD在 rebase 开始时会自动记录原始位置，git reset --hard ORIG_HEAD是标准的回退方式，比翻 reflog 快。
注意：
reflog默认只保留 90 天，且是本地记录，不会随仓库推送。如果你要做的 rebase 跨越大量提交，建议顺手打个标签git tag backup-before-rebase，比依赖 reflog 稳妥。
3.2 交互式 rebase 的指令表和常用组合
普通的git rebase main只做搬运，交互式模式才是真正有用的部分：
# 整理最近 5 个提交 git rebase -i HEAD~5 # 或者从主干分叉点开始整理 git rebase -i $(git merge-base HEAD main)第二条命令更实用，因为它不需要你数提交个数。git merge-base会算出分叉点，无论你在这条分支上做了 3 个还是 30 个提交，都是从这里开始整理。
打开编辑器后是这样一个列表，每行一个提交，从上到下是时间顺序：
pick a1b2c3d 添加导出按钮 pick d4e5f6a 修复导出按钮样式 pick b7c8d9e 临时调试日志 pick e1f2a3b 补充导出参数校验可用的指令如下：
| 指令 | 缩写 | 作用 |
|---|---|---|
pick | p | 保留该提交 |
reword | r | 保留内容，改提交说明 |
edit | e | 停下来，允许修改内容或拆分 |
squash | s | 合并进上一个提交，保留说明供编辑 |
fixup | f | 合并进上一个提交，丢弃本提交说明 |
drop | d | 删除该提交 |
exec | x | 执行一条 shell 命令 |
break | b | 暂停，回到命令行手动操作 |
我在实际项目里最常见的组合是f加r。开发过程中会积累大量"修修补补"的提交，比如fix typo、改一下变量名、调试日志。推送前统一整理：
pick a1b2c3d 添加导出按钮 f d4e5f6a 修复导出按钮样式 r b7c8d9e 补充导出参数校验 d e1f2a3b 临时调试日志保存退出后，Git 会依次执行：保留第一个、把第二个折叠进去、在第三个处停下来让你改说明、把第四个删掉。整个过程结束后，原本 4 个提交变成 2 个，历史干净了很多。
3.3 用fixup!提交配合--autosquash省掉手动排序
上面那种手动编辑列表的方式，在提交多的时候容易排错行。我后来改用一个更省心的流程：日常提交时就用fixup!前缀标记它属于哪个提交。
# 发现之前某个提交有问题，直接修，然后： git commit --fixup=a1b2c3d这会生成一个说明为fixup! 添加导出按钮的提交。之后整理时加上--autosquash：
git rebase -i --autosquash $(git merge-base HEAD main)编辑器打开时，那些fixup!提交已经自动排到目标提交后面并标记为fixup了，你只需要确认一下保存退出。这个习惯养成之后，我基本不再手动编辑 rebase 列表，出错率大幅下降。
想让它成为默认行为：
git config --global rebase.autoSquash true另外，--fixup=amend:<hash>这个变体（Git 2.32+）可以在修正内容的同时把提交说明也一起改掉，适合那种"提交说明写错了但已经提交了"的情况。
4. 冲突卡在中途时的完整排查链路
4.1 先分清当前处在哪个阶段
rebase 遇到冲突会停下来，此时终端提示大概是这样：
CONFLICT (content): Merge conflict in src/export.js error: could not apply d4e5f6a... 修复导出按钮样式 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue".这时候第一件事不是急着改文件，而是先搞清楚状态：
git status输出会明确告诉你两件事：当前正在应用哪个提交（interactive rebase in progress; onto xxxx），以及哪些文件有冲突。我把这个阶段的排查拆成三步：
第一步，看冲突文件列表，判断冲突规模。如果只有一两个文件，直接手动改；如果十几个文件全红，那大概率是基底选错了，或者中间夹了一次大规模重构，这种情况先--abort重新评估比硬解更省时间。
第二步，看冲突内容。冲突标记长这样：
<<<<<<< HEAD const result = exportData(list); ======= const result = exportData(list, options); >>>>>>> d4e5f6a (修复导出按钮样式)HEAD那一侧是基底分支（你 rebase 到的目标）的内容，下面那一侧是你正在应用的那个提交的内容。注意较新版本的 Git 会在标记里带上提交说明，这个信息很有用，能让你立刻知道这段改动是为了什么。
第三步，决定解决策略。如果是单纯的"两边都改了同一行但逻辑不冲突"，手动合并；如果是"这个提交的改动已经被基底分支包含了"，用git checkout --ours <file>取基底版本。
这里有个容易踩的问题：rebase 过程中
--ours和--theirs的语义和 merge 时是相反的。因为 rebase 是逐个把你的提交"重放"到基底上，此刻HEAD指向的是基底，所以--ours拿到的是基底分支的内容，--theirs才是你分支上的改动。我第一次遇到时凭直觉用反了，白改了半天。
4.2--continue、--skip、--abort怎么选
三个收尾命令对应三种判断：
# 冲突已解决，继续应用下一个提交 git add <files> git rebase --continue # 这个提交的改动整体不需要了，跳过它 git rebase --skip # 放弃整个 rebase，回到开始前的状态 git rebase --abort选择的逻辑很清晰：改动还要不要。要，解冲突后--continue；不要，--skip；整个过程判断有误，--abort重来。
有个细节值得说：--skip跳过的提交不会消失，它在 reflog 和ORIG_HEAD指向的旧历史里还在，只是不在当前分支上了。所以误跳也不用慌。
还有一种更隐蔽的情况：解完冲突git add了，但--continue报错说"没有可应用的改动"。这通常是因为你把这个提交的改动全部还原成了基底的样子，Git 认为这是个空提交。此时可以直接git rebase --skip，或者用git commit --allow-empty保留它（如果你确实需要这个提交节点存在）。
4.3 让重复冲突只解一次
多分支并行开发时，同一个冲突你可能要解好几遍：feature/a解一次，feature/b又解一次，因为两条分支都改了同一块代码。rerere就是为这个场景设计的。
git config --global rerere.enabled true开启后，Git 会把你每次解决冲突的结果记录下来，下次遇到完全相同的冲突时自动套用。第一次解完执行git add时，Git 会把这个解法存进.git/rr-cache/。
我一般还会开rerere.autoupdate：
git config --global rerere.autoupdate true这样自动套用之后会直接帮你git add，连这一步都省了。输出里看到Resolved 'xxx' using previous resolution就是这个机制在工作。
实测下来，这个配置在"主干频繁变动 + 多条特性分支都要追平"的场景里能省掉大量重复劳动。开启成本几乎为零，建议直接加上。
5. 历史被改写之后：推送、CI 与协作连锁反应
5.1 为什么我坚持用--force-with-lease
rebase 之后推送必然要强制覆盖，问题是--force太危险。它会无条件把远端分支覆盖成你本地的样子，如果这期间有同事往这条分支推了东西，那些提交在远端就没了，对方下次拉取时会发现自己提交记录消失了。
--force-with-lease加了一层校验：只有在"远端分支的位置和本地记录的远程跟踪引用一致"时才允许覆盖。换句话说，如果这期间有人推过东西，你的本地origin/feature还是旧的，校验不通过，推送被拒绝。
git push --force-with-lease origin feature/order-export被拒绝时不要直接上--force，先拉下来看看对方推了什么：
git fetch origin git log HEAD..origin/feature/order-export如果对方的提交确实需要保留，重新 rebase 一次把这些提交带上，再推。
还有一个更严格的形式：--force-with-lease=<分支名>:<期望的哈希>，明确指定你期望远端处于哪个位置。适合在多分支同时操作、本地跟踪引用可能过期的场景。我现在的习惯是把它设成别名：
git config --global alias.pushf "push --force-with-lease"5.2 团队里关于 rebase 的几条共识
技术手段解决不了协作问题，还是得定规矩。我参与过的几个项目最后都收敛到这么几条：
第一，主干和发布分支永远不 rebase。这条没有例外。发布分支上打过的 tag、生成过的制品、对外公布过的版本号，都锚定在具体哈希上，改写历史等于让这些东西全部失效。
第二，个人分支 rebase 前先确认没有人在基于它工作。判断方法很土但有效：在群里问一句，或者看这条分支最近有没有别人的提交。有 CI 的系统可以看构建记录，如果有别人的流水线挂在上面，就不要动。
第三，rebase 之后立刻推送，不要攒着。本地改写了历史但没推，中间又做了新提交，这时候如果别人基于旧历史推了东西，你就得处理一次真正的分叉合并，比一开始就推要麻烦得多。
第四，CI 缓存要注意失效。这个坑比较隐蔽：很多流水线用提交哈希做缓存键，rebase 之后哈希全变，缓存全部失效，一次全量构建可能比平时慢好几倍。我们后来把缓存键改成基于文件内容哈希或者分支名加依赖锁文件，才绕开这个问题。如果你的项目构建时间长，rebase 前最好挑个低峰时段。
还有一点关于签名的：rebase 会重新生成提交，原来提交上的签名通常保不住。如果项目要求所有提交必须签名，rebase 后得重新签一遍：
git rebase --gpg-sign main这个参数会让 rebase 过程中生成的每个提交都重新签名。没这个需求的话可以忽略。
6. 几个我踩过的问题和日常习惯
6.1 那些年 rebase 出过的事故
第一个事故是拿 rebase 当 merge 用。当时接手一个多人协作的集成分支，看历史太乱，想着"顺手清理一下"，直接git rebase main推了上去。结果另外两个人的本地分支全部失效，他们下次 pull 时面对一堆冲突，花了一下午才恢复。这件事之后我给自己定了条原则：动手前先看git log --all --oneline --graph，确认这条分支上有几个人的提交。有第二个人，就不碰。
第二个事故是解冲突时误删代码。一次 rebase 涉及 20 多个提交，连续解了七八轮冲突，人已经麻了，某一轮直接把整块逻辑删了当"冲突解决"。当时没发现，测试环境跑了一周才有人报某个边界条件失效。后来我加了两个习惯：解完冲突先git diff ORIG_HEAD看整体差异，再用git range-diff逐提交核对。多花五分钟，能挡掉这类问题。
第三个事故更基础：在脏工作区直接 rebase。git rebase要求工作区干净，但我见过用--autostash之后 stash 恢复失败的情况，改动混进了某个提交里，很难剥离。现在的做法是 rebase 前一定git status确认干净，有改动就先git stash并打上说明，或者干脆提交一个临时提交待会儿再整理。
6.2 几个提升效率的配置和习惯
日常用得最多的几个配置，一条条说：
# 拉取时默认用 rebase，避免产生无意义的合并提交 git config --global pull.rebase true # rebase 时自动整理 fixup! 提交 git config --global rebase.autoSquash true # 自动更新分支栈上的其他引用 git config --global rebase.updateRefs true # 记住冲突解法 git config --global rerere.enabled true # 推送默认带 lease 保护 git config --global alias.pushf "push --force-with-lease" # 快速查看当前分支相对主干的提交 git config --global alias.unpushed "log --oneline main..HEAD"最后这个别名我几乎每小时都用一次，尤其是准备 rebase 之前，先看一遍这条分支上到底有哪些提交、哪些需要 squash、哪些压根不该存在。
另外补一个我认为最值得养成的小习惯：每次提交前想一下"这个提交如果单独拿出来，能不能独立说明一件事"。能，就直接提交；不能，就想想是不是该用fixup!挂到之前的提交上。这个思维习惯比任何工具都管用，它能让你的分支在 rebase 时少很多整理工作，因为你提交的时候就已经是整理过的状态了。我见过太多人开发时随手git commit -m "update"，最后花两小时 rebase 整理，其实这部分成本在最开始就能省掉。
再补一句关于pull.rebase的个人体会：这个配置设成 true 之后，git pull相当于git fetch加git rebase，本地提交会被重放到远端最新位置。好处是历史线性，坏处是如果本地有一堆未整理的提交，rebase 过程中可能连续冲突。我的折中做法是日常保持这个配置开启，但本地提交积累到五个以上时，先手动git fetch看一眼远端变了多少，冲突多的话先整理本地提交再拉，比边拉边解冲突从容得多。
