峰瑞资本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: Y