峰瑞资本1. 提交历史为什么需要整容：一次糟糕的 merge 引发的思考
先讲一个我自己的真实经历。去年有段时间，我在一个功能分支上开发一个新模块，前后花了将近两周。需求改了三版，中间还穿插着修 bug、调格式、改命名、删无用文件。每完成一个节点我就顺手 commit 一次，commit message 写得也随意，比如"改了点东西"、"再改一下"、"终于跑通了"。结果功能合并回主分支时，我数了一下，这个功能相关的提交有 47 个，其中至少有 20 个属于"当时有用、事后完全没必要单独存在"的中间态提交。
代码审查的同事看着那一长串提交记录，问了我一句："你这 47 次提交，哪个是能对应到需求文档里的功能点的？"我沉默了。这个经历让我彻底意识到，提交历史不是写给自己一个人看的流水账，它是整个团队的协作日志。
很多人会觉得："反正代码最终能跑就行，提交历史乱一点有什么关系？"关系很大。当你需要回溯一个 bug 是在哪次提交引入的、当你需要把某个功能单独 cherry-pick 到别的分支、当新同事通过 git log 理解项目演进脉络时，一份混乱的提交历史会让这些操作的成本成倍上升。而 Git 提供的 rebase 命令，就是专门用来整理提交历史的工具。
这篇内容我围绕 rebase 的核心用法来讲，包括它和 merge 的本质区别、怎么用 rebase 把分支提交整理干净、交互式 rebase 的详细操作手法，以及我踩过的那些坑和对应的救援方案。适合已经掌握 Git 基本操作（add、commit、push、pull）但想进一步提升协作效率的同学阅读。
注意一点：rebase 是消耗型的操作，它会重写提交哈希。在团队协作场景中使用时，必须先明确使用边界，否则容易把队友的本地分支搞乱。后面我会专门讲这个安全边界。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. rebase 的底层机制：它和 merge 到底差在哪
2.1 一句话理解 rebase 在做什么
rebase 的中文翻译叫"变基"，这个翻译虽然拗口，但非常准确。你想象一条分支，它的"基地"是它分叉出去的那个点。比如你在 main 分支的 commit C 位置拉了一条 feature 分支，feature 分支上又提交了 D 和 E，那么 D 和 E 的"基地"就是 C。rebase 做的事情，就是把 D 和 E 重新"嫁接"到另一个基地上——比如 main 分支后来推进到了 F 和 G，你执行 rebase 之后，D 和 E 会被重新应用到 G 的后面，变成 D' 和 E'。
2.2 和 merge 对比：为什么两者的历史形状完全不同
merge 的思路是"殊途同归"。它保留两条分支各自的提交轨迹，然后生成一个新的合并提交把两条轨迹连接起来。从提交图上看，merge 会产生分叉和交汇，历史是一条有分支有合流的网。
rebase 的思路是"平铺直叙"。它把当前分支上的提交一个个摘下来，按顺序重新应用到目标分支的最新提交之上，最终你得到一条线性的提交历史，看不到任何分叉。
从视觉效果上说：
- merge 的历史像一张地铁线路图，有交汇站、有分支线
- rebase 的历史像一条高速公路，从头到尾一条直的
这两种方式没有绝对的优劣，但场景不同，诉求就不同。如果你希望保留"这个功能确实是在那个时间点并行开发出来的"这一事实，merge 是诚实的记录；如果你更看重提交历史的可读性、可回溯性，希望每个功能对应一段清晰的提交序列，rebase 是更好的选择。
我个人的判断标准很简单：功能分支在自己手里、还没有推送或只有自己在用时，用 rebase 整理；多人共享的分支，用 merge 保留真实的合并点。 团队协同作战的时候，二者配合使用才是常态。
2.3 rebase 的三个隐藏特性：重写、移动、压缩
真正理解 rebase，需要记住它的底层操作其实包含三个能力：
- 重写提交：因为提交的父指针变了，新生成提交的 SHA-1 哈希值必然变化，这就是"重写"。
- 移动提交：把分支上的提交从一个位置挪到另一个位置，对应"变基"。
- 压缩提交：在交互式 rebase 中，可以把多个提交合并成一个，这是整理历史最常用的能力。
这三个特性共同构成了 rebase 的全部用法基础。后面讲到的所有操作手法，本质都是这三个特性的组合运用。
2.4 初次使用前的环境检查清单
正式操作之前，建议先确认几件事，避免在错误状态下执行 rebase 导致混乱：
- 当前工作区是干净的。执行
git status，确认没有未提交的修改。如果有，先 commit 或者 stash 暂存起来。 - 确认你当前所在的分支。
git branch看一下，避免在 main 分支上执行了针对 feature 分支的 rebase。 - 确认目标分支的最新状态。先
git fetch，把远程仓库的最新引用同步到本地，再基于最新的远程状态进行 rebase。
这三步是基本功，但我在带新人时发现，绝大多数 rebase 翻车事故，都是因为没有做第 1 步或第 2 步。工作区有未提交修改时执行 rebase，Git 会报错 "cannot rebase: You have unstaged changes"；在错误的分支上执行 rebase，则会把整个分支历史搞乱。
3. 基础变基实操：把分支上的提交"平移"到最新主线
3.1 最常见的场景：功能分支同步主分支的最新代码
这是 rebase 最基础、也最常用的场景。你在 feature/login 分支上开发登录功能，开发过程中别的同事往 main 分支上合入了支付模块的代码。你现在想拿到这些新代码，但又不想通过 merge 产生一个多余的合并提交，那么就可以用 rebase：
bash复制# 先切到 feature/login 分支（如果还没在的话）
git checkout feature/login
# 执行变基，把当前分支的提交平移到 main 的最新提交之后
git rebase main
执行过程中，Git 会依次把 feature/login 上的提交"摘下来"，逐个应用到 main 的最新提交之后。如果某个提交和 main 上的新代码产生冲突，Git 会在应用到这个提交时停下来，提示你解决冲突。
冲突解决之后，执行：
bash复制git add <冲突解决后的文件>
git rebase --continue
Git 会继续应用后面的提交。全部应用完成之后，你的 feature/login 分支历史就变成了一条直线，main 分支的最新代码被"垫"在了下面，你的提交被"垫"在了上面。
3.2 变基时发生冲突怎么办：一步步来
很多人第一次遇到 rebase 冲突会很慌，因为感觉操作和 merge 冲突不太一样。其实核心逻辑是一样的：Git 把冲突文件的状态标记为 "both modified"，你用编辑器打开文件，看到 <<<<<<<、=======、>>>>>>> 标记，手动整理后再 add 即可。
不同的是后续动作：
- merge 冲突解决后，执行
git merge --continue - rebase 冲突解决后，执行
git rebase --continue
还有一个容易混淆的点：rebase 过程中如果想放弃这次操作、回到变基之前的状态，执行：
bash复制git rebase --abort
这个命令会自动把分支恢复到刚开始 rebase 前的位置。如果你解决冲突解到一半发现思路不对，或者冲突太多不想处理了，直接 abort 是保命操作。
我见过有些同学在 rebase 冲突时用了 git rebase --skip，这个命令是"跳过当前这个提交，不应用它了"。除非你明确知道这个提交的内容不要了，否则不要轻易用 skip。我曾经因为误用 skip，把分支上一个重要的中间提交丢掉了，后来花了半天时间从 reflog 里找回来。后面我会专门讲 reflog 救援。
3.3 变基与推送到远程分支的配合
如果你的 feature 分支已经推送到远程仓库，rebae 之后本地分支的历史就和远程分支不一致了。这时候普通的 git push 会被拒，因为远程分支的旧历史和本地的新历史已经分叉。
解决办法是强制推送：
bash复制git push --force-with-lease
注意，我强烈建议不要用 git push --force，也就是不带 --with-lease 参数的强制推送。--force-with-lease 的优势在于，它会在推送前检查远程分支的最新状态是否和你上次 fetch 到的状态一致，只有在一致的情况下才执行强制推送。这可以防止你覆盖掉同事刚刚推上去的提交。
如果你发现 --force-with-lease 推送被拒绝，说明远程分支在你 fetch 之后又有新的提交进来，那就需要重新 fetch、rebase 一次，再推送。这个机制是安全兜底的。
这里要特别强调一个场景边界：如果远程 feature 分支是你一个人独享的，rebase 后强制推送没问题。如果这个分支有多个人在协作，强制推送会重置对方的本地历史，造成极大混乱。 这种多人共享分支，不要用 rebase 整理历史，用 merge 或者直接追加新的提交更安全。
4. 交互式变基：压缩、重写、排序的完整手法
4.1 交互式变基的进入方式和命令面板
真正让 rebase 发挥强大整理能力的是交互式变基。进入方式是在 rebase 后面加 -i 参数，同时指定一个范围：
bash复制git rebase -i HEAD~5
这表示对当前分支最近 5 个提交进行交互式变基。执行后 Git 会打开一个编辑器（默认是 Vim），里面列出了这 5 个提交的哈希前缀和提交信息，每一行开头是一个命令关键字：
code复制pick 3a2b1c0 feat: add login page
pick 7d9e4f1 fix: fix typo in login form
pick 8c1a2b3 feat: add remember me checkbox
pick 4e5f6a7 style: adjust button spacing
pick 9b8c7d6 fix: fix login api error
每一行开头的 pick 表示"保留这个提交"。常用的替换命令有：
| 命令 | 缩写 | 作用 |
|---|---|---|
| pick | p | 保留该提交 |
| reword | r | 保留提交内容，但重新编辑提交信息 |
| edit | e | 保留提交，但停下来让你修改内容 |
| squash | s | 把这个提交合并到上一个提交中，同时合并提交信息 |
| fixup | f | 把这个提交合并到上一个提交中，丢弃该提交的信息 |
| drop | d | 删除该提交 |
4.2 用 squash 把一堆小提交压成一个功能提交
拿我开头说的那个例子。一个登录功能开发了两周，有几十个中间提交。合并回主分支之前，我想把它们整理成一个清晰的"feat: 实现登录功能"提交。操作如下：
首先查看最近提交的列表，确认我要整理的提交范围。假设从某个节点开始往后的 20 个提交都属于登录功能，执行：
bash复制git rebase -i HEAD~20
进入编辑器后，把第一个提交保留为 pick，其余 19 个都改成 squash：
code复制pick 3a2b1c0 feat: add login page
squash 7d9e4f1 fix: fix typo in login form
squash 8c1a2b3 feat: add remember me checkbox
squash 4e5f6a7 style: adjust button spacing
squash 9b8c7d6 fix: fix login api error
...
保存退出后，Git 会依次把这 19 个提交的内容合并到第一个提交里，同时打开一个编辑器，让你合并提交信息。最终你得到一个提交，提交内容包含了这 20 个提交的所有改动。
这里有一个技巧：如果你不关心被合并提交的 message，只想保留第一个提交的 message，可以把命令换成 fixup。效果和 squash 一样是合并内容，但直接丢弃后面提交的信息，不会弹出编辑器让你编辑一份冗长的合并说明。squash 适合你想重新组织提交信息时用，fixup 适合你只想合并不想改信息时用。
4.3 reword 和 edit 的具体用法与配合
除了压缩，日常使用频率较高的还有 reword 和 edit。
reword 用来修改提交信息。我在实际操作中经常遇到这种情况：代码写完了，提交信息写得比较随意，比如"aaa"、"test"、"update"。等整个功能完成、准备合并前，我想把信息改成规范的格式，比如"feat: add user profile page"。
操作方式很简单：
bash复制git rebase -i HEAD~3
把目标提交行前的 pick 改成 reword，保存退出。Git 会先停下来，打开编辑器让你修改提交信息，保存后继续应用后续提交。
edit 用来修改提交内容本身。这个稍微复杂一点，但非常实用。我先说一个具体场景：开发过程中发现之前某次提交里有安全敏感信息（比如硬编码的密钥），或者少加了一个文件，想追加进去，但不想增加一个"补丁"提交。
操作步骤：
- 在交互式 rebase 里，把目标提交行前的
pick改成edit - 保存退出，Git 会在那个提交应用完、下一个提交应用前停下来
- 此时修改文件、
git add，然后执行git commit --amend把改动并入当前提交 - 执行
git rebase --continue继续完成剩余提交
这个模式下，你实际上是在"重写历史"，把之前的提交改造成你想要的样子。效果非常干净，不会留下一个"fix: 补上昨天漏掉的文件"这种冗余提交。
4.4 调整提交顺序和删除无用提交
交互式 rebase 的编辑器里，行的排列顺序就是提交的应用顺序。你可以直接调整行的上下位置，来改变提交的先后顺序。这在某些场景下很关键，比如你想把一个"重构提取公共方法"的提交移到最前面，让后续的功能提交都基于它。
实现方式：在 Vim 编辑器中，把要移动的行剪切（Vim 中是 dd）到新位置（p 粘贴），保存退出即可。Git 会按照新的顺序重新应用提交。调整顺序时可能会产生冲突，因为提交的上下文变了。解决方式和前面讲的冲突处理一致。
删除一个提交，更简单——把那一行删掉，或者把 pick 改成 drop，保存退出。这个提交的内容就从这个分支上消失了。
注意：drop 是真正从这个分支历史里移除一次提交，包括它的改动内容。如果这个提交的改动在后面的提交中被引用了，drop 之后会因为内容缺漏产生冲突。所以在 drop 之前，确认这个提交的内容确实不再需要。
5. 变基的常见事故现场与救援方案
5.1 事故一：rebase 到一半想反悔
最常见的翻车现场是：rebase 过程中冲突太多，处理了几个之后心态崩了，想回到开始之前的状态。
保命命令是：
bash复制git rebase --abort
只要你在 rebase 过程中，这个命令就能把分支恢复到执行 rebase 之前的状态。但是有个前提：你必须在 rebase 正在进行时使用它。如果你已经 git rebase --continue 全部完成了，abort 就没用了。
如果你在 rebase 完成之后才发现结果不对，还有一个救援手段：reflog。Git 的 reflog 记录了 HEAD 指针的所有移动轨迹，你可以通过它找到 rebase 之前 HEAD 指向的位置。
bash复制git reflog
输出会显示类似这样的记录：
code复制a1b2c3d HEAD@{0}: rebase (finish): returning to refs/heads/feature/login
e4f5a6b HEAD@{1}: rebase (pick): feat: add login page
...
找到 rebase 之前的那条记录（一般是最开始 rebase 前的 "checkout: moving from main to feature/login" 或者 "commit: ..." 那一条），记下它的哈希值，然后：
bash复制git reset --hard <那个哈希>
就能回到 rebase 之前的状态。reflog 默认保留 90 天，所以短暂的误操作都能救回来。我把 reflog 称为"Git 后悔药"，每个用 Git 的人都应该知道它。
5.2 事故二：把已推送的分支 rebase 后强制推送，导致队友本地历史漂移
这个事故的惨烈程度不亚于删库。场景是这样的：你们团队三个人在一个 feature 分支上协作。你把自己负责的部分完成推到远程了，后来觉得自己提交太碎，想整理一下，就执行了交互式 rebase 把 5 个提交压缩成了 2 个，然后用 git push --force 强制推送。同事 A 和同事 B 的本地还留着旧的历史，他们下次 pull 的时候会发现远程历史和本地历史完全对不上，Git 会要求他们 rebase 或者 merge，然后产生一堆莫名其妙的重复提交。
正确的做法是：多人协作的分支不要做 rebase 整理。 如果一定要整理，提前和所有协作者打招呼，让他们先处理完自己的本地提交，并且协商好一个统一的时间窗口去 reset 本地分支。
如果你已经因为强制推送搞乱了队友的本地环境，救援方法是让队友用 reflog 找到自己本地正确的提交状态，然后 git reset --hard 回到那个状态。但这属于把简单问题复杂化了，最好的对策是从源头避免。
5.3 事故三：rebase 时误用 --skip 丢掉了提交
前面提到过一次，这里展开讲。--skip 的本意是"跳过当前这个有冲突的提交"，把它从分支中移除。但很多人在界面提示冲突时，看到 "fix conflicts and then run 'git rebase --continue'" 觉得不知道怎么处理，随手试了一下 --skip，结果这个提交的改动全部丢失了。
如果你发现自己因为 --skip 丢掉了某个提交的改动，不要慌，一样可以用 reflog 找回。找回思路有两种：
- 用
git reflog找到 rebase 之前的 HEAD 位置，git reset --hard过去，然后重新执行 rebase，这次仔细处理冲突。 - 用
git reflog找到那个提交的哈希（rebase 之前它还在你的分支上），用git cherry-pick <哈希>单独把它拿回来。
两种方式都能救回丢失的提交。这里我想强调的是：--skip 和 --abort 的区别要刻在脑子里。abort 是"整个不玩了，回到最初状态"；skip 是"这个提交不要了，继续后面的"。当你拿不准时，用 abort 永远是更安全的选择。
5.4 事故四：rebase 之后再 push 被拒绝
rebase 完成后你要推送，结果提示：
code复制 ! [rejected] feature/login -> feature/login (non-fast-forward)
这个提示的意思是：远程分支的提交历史和你本地的不一致，普通的推送无法覆盖。解决方案前面已经提到，用 git push --force-with-lease。
但这里有一个进阶问题：如果你的分支是从远程拉下来的，远程状态在你 fetch 之后又变了（比如队友推了新提交），--force-with-lease 会拒绝推送并提示远程有更新。这时候的处理顺序是：
git fetch origin获取最新状态git rebase origin/feature/login把你的提交重新变基到最新的远程提交之上- 再
git push --force-with-lease
这样就能在保留队友新提交的基础上，发布你自己的整理结果。这一步是多人协作下使用 rebase 的标准操作流程，建议大家能熟练到形成肌肉记忆。
6. 安全使用 rebase 的铁律与我的个人思路
6.1 什么情况下可以放心用 rebase
我根据多年实践经验，总结了一套自己的使用准则，分享给大家：
- 本地分支、还没有推送过的提交：随便 rebase，想怎么整理就怎么整理，这是 rebase 的绝对安全区。
- 远程分支只有你一个人在推：可以整理，但整理后要用
--force-with-lease推送，并且要记住自己做过这次操作，免得之后看 log 觉得奇怪。 - 多人共享分支：不要用 rebase 整理历史。老老实实用 merge 合并新代码，保持真实的分叉和合流历史。
- 主分支（main/master）：永远不要对主分支执行 rebase。主分支是全团队的权威来源，任何历史重写都会波及所有人。
6.2 用 rebase 整理提交的最佳时机
很多初学者会问："我应该在什么时候做 rebase 整理？是每次提交前吗？还是功能完成时？"
我的建议是：在功能完成、准备合并回主分支之前做一次整理。 具体来说，当一个功能分支的开发工作全部结束、你自己 review 一遍代码确认没问题时，进行一次交互式 rebase，把这个功能相关的提交整理成有逻辑、有层次的提交序列。
这个节奏的好处是：
- 开发过程中你不需要频繁停下来整理历史，思路不会被打断
- 功能完成时，你已经很清楚哪些提交是核心步骤、哪些是过程中的临时修正，整理起来思路清晰
- 合并后的主分支历史干净，每个功能对应一个或少数几个高质量的提交，后续回溯成本很低
6.3 一个我一直在用的协作流程建议
结合以上所有内容，我讲一下我目前在团队中推行的 Git 协作流程，供大家参考：
- 每个人的功能分支从 main 拉出后，开发过程中随意提交，代码是自己的草稿本，怎么方便怎么来
- 功能完成后、推送远程之前，用
git rebase -i整理一次提交历史，把碎提交压成有意义的提交 - 推送到远程 feature 分支，发起代码审查
- 审查通过后，使用 merge 合回 main，保留真实的合并节点
- 如果功能开发周期较长、需要经常同步 main 的新代码，定期执行
git rebase main，保持分支线性和最新状态，减少最后合并时的冲突量
这个流程下，主分支历史是清晰线性的，功能分支在合并前也是经过整理的，而多人共享分支带来的风险被最小化。我自己用这个流程跑了两年多，团队成员从最初觉得 rebase 畏难，到现在已经把 rebase -i 当成习惯动作。变革的过程需要一些耐心，但收益是实打实的。
6.4 最后提一个实际操作的细节：配置一个友好的交互式编辑器
交互式 rebase 默认使用 Vim 编辑器。很多不熟悉 Vim 的同学，第一次进入编辑界面后不知道怎么操作，屏幕上满屏的 pick，不知道从哪里下手。这里分享两个配置调整：
想让交互式 rebase 使用 VSCode 作为编辑器：
bash复制git config --global core.editor "code --wait"
想让交互式 rebase 打开 Sublime Text：
bash复制git config --global core.editor "subl -w"
设置完成之后，每次执行 git rebase -i 就会自动打开你熟悉的图形编辑器，操作起来舒服很多。这个小配置能大幅度降低交互式 rebase 的上手门槛。
还有一个小技巧：如果你觉得每次改动命令关键字还要手动输入很麻烦，在 Vim 里可以用 :%s/pick/squash/g 批量化替换关键词，几秒钟就能把一长串提交全部改成 squash。这个命令的意思是把所有行的 pick 替换为 squash，全局生效。用熟了之后，整理几十个提交都是秒级操作。
6.5 从实际工作中学到的几个经验
最后说点我在实际工作里学到的、文档里不太会写的东西。
第一，rebase 不是万能的整理工具，有些场景它确实不如 merge。比如你想保留"这个功能是并行开发的"这一事实，或者需要清晰地标注合并时间点，merge 更合适。工具的选择要服务于你的目标，不要为了用 rebase 而用 rebase。
第二，commit message 的质量比提交的数量更重要。哪怕一个功能只有一次提交，message 写得描述不清，照样是糟糕的历史。反过来，即使有多次提交，只要 message 写得清晰、逻辑层次分明，历史也是可读的。整理提交历史时，不仅要压缩数量，更要重写 message，让它像一篇好文章的小标题一样简洁有力。
第三，rebase 操作前，"先 stash 或 commit 再操作"是我最想强调的习惯。工作区不干净时，任何 Git 历史操作都可能引入额外的问题。宁可多花十秒钟存一下，也不要在脏状态下冒风险。
第四，多练习 reflog 的用法。我见过不少同事，遇到 rebase 出问题就慌了，其实只要 reflog 在手，绝大多数误操作都能恢复。花半个小时把 reflog 常用命令练熟，比任何预防措施都实在。