遇见高中生前阵子帮一个朋友排查代码问题，他递给我一台电脑，我打开仓库历史一看，整整二十多个提交，每个提交的信息不是"fix"就是"update"，有些还是"aaaa"、"test"。而真正的业务改动就这么被淹没在一堆垃圾提交里，我足足花了半个多小时才从历史里拼凑出他到底做了些什么。这种体验，我相信每个用Git的人都经历过。
Git给了我们很强的能力去管理代码历史，而rebase就是其中被低估、也常常被误解的一个高级技巧。它最核心的价值，就是让我们在提交还没有被推送到远端、没有被别人依赖的时候，把一团乱麻整理成一条清晰的业务主线。这篇文章不跟你讲那些枯燥的底层原理，我会从真实开发场景出发，把rebase的用法、交互式操作、冲突处理、以及什么情况下千万别用rebase，一次说透。
1. 提交历史是怎么失控的
1.1 失控时的典型症状
提交历史变乱，不是一天造成的，通常有几个明显信号。第一，提交信息毫无语义，比如"save"、"ddd"、"1"，看到这种信息你根本不知道这次改动是为了什么。第二，一个功能提交被拆得七零八落，比如同一个登录功能的开发，光是修改就占了五六个commit，中间还掺杂着无关的格式化改动。第三，合并记录满天飞，频繁从主分支往功能分支merge，导致历史像一张蜘蛛网，翻起来又累又乱。
我见过最夸张的一次，一个新同事开发一个两周的功能，最后合并时功能分支上有八十多个提交，其中真正的代码变更只有八九百行，剩下全是一堆无意义的中间状态。
1.2 混乱历史会造成什么真实成本
提交历史混乱的代价，不是"看起来不舒服"这么简单。第一个代价是代码评审效率直线下降。当你打开一个PR，里面几十个提交，消息都是"fix"、"update"，评审人只能在代码diff里自己找逻辑，完全没法按照提交逐个理解你的思路。第二个代价是定位问题变得极其困难。线上出了bug，你第一反应是看看是哪个提交引入的，但如果每个提交都是无意义的中间态，git bisect基本派不上用场。
第三个代价，也是容易被忽略的，是历史信息作为"团队知识"的价值被抹掉了。好的提交历史，本身就是一个项目演进的时间线，它记录了每一个决策的来龙去脉。如果提交信息写得乱七八糟，后人翻历史的时候，等于面对一堆面目模糊的碎片。
1.3 一个让我彻底重视rebase的场景
我自己在这上面栽过跟头。当时做一个活动页面的需求，因为赶时间，我几乎每改一个小问题就提交一次，从早上到晚上攒了十三个提交，信息从"A"到"M"乱排。第二天要提测，我突然发现有个老功能被我改坏了，但怎么也想不起来是哪个提交改动了那部分逻辑。
十三个提交，挨个看一遍代码，感觉比写这个功能还累。最后我硬着头皮花了快一个小时才定位到问题。那次之后我就下定决心，提交历史必须是能讲故事的东西，而不是一锅粥。而rebase就是整理这锅粥的那把勺子。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. rebase到底是什么，它和merge的本质差异
2.1 先搞懂commit的结构，再谈rebase
在讲rebase之前，我建议你先理解一个Git提交的底层结构。每一个commit在Git里都是一个对象，它除了记录代码快照，还保存了作者、时间、提交信息，以及最重要的——它的父提交指针。正因为有这个父指针，提交之间才能串联成一条链。
你每次在某个分支上提交，实际上就是在当前链的末端接上一个新节点。而rebase这个动作，通俗地说，就是把你分支上的一系列提交"摘下来"，在另一个基底上重新"栽"一遍。举个例子，你有三个提交A、B、C，都是基于主分支的M0节点开发的。如果主分支在你开发期间又推进到了M1，git rebase main做的事情就是：先找到A、B、C和主分支的公共祖先M0，然后把A、B、C依次在M1上面重放一遍，最终得到新的提交A1、B1、C1。
2.2 一个帮助理解rebase的生活类比
我一直觉得，rebase跟"誊写草稿"特别像。你写一篇文章，不可能一口气就写出一版完美的，你肯定先有涂涂改改的草稿，里面有错别字、有思路中断的片段、有随手写的临时内容。草稿的作用是帮你把思路理清，但绝对不会直接拿给编辑看。你会花时间把草稿重新誊写一遍，删除