学术入门1. 为什么你的提交历史需要在代码评审前“改头换面”
做代码评审的时候，很多人只盯着 diff 看，却忽略了一件同样重要的事：提交历史本身。一个功能分支开发了三天，提交记录可能是这样子的——“wip”、“fix”、“update2”、“final”，运气差点还能看到“真的最终版”和“别提交这个”。说实话，这种历史推到远端之后，别说同事看不懂，过两周你自己回来看都得愣一下：这到底改了个啥？
Git 的 rebase 就是专门用来解决这类问题的。它的核心能力在于，你可以在推送之前，把一堆乱糟糟的提交整理成一条清晰、有逻辑、每个提交都只做一件事的历史线。代码评审的人顺着提交历史读下来，就像看一篇结构分明的文章，而不是满地涂鸦的草稿纸。
这篇文章不打算讲 rebase 的全部底层原理，那是 Git 官方文档干的事。我按自己做项目的实际经验，把 rebase 拆成几个最常见的用法场景——合并提交、修改提交信息、调整提交顺序、处理冲突、以及最重要的“什么时候千万别用”的边界判断。每个场景都会给可复现的操作步骤和我在实战中踩过的坑，你可以直接照抄，省得自己再去试错。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. rebase 和 merge 的本质区别：别再把历史“焊死”了
2.1 merge 留下的“缝合痕迹”到底好不好
团队里一旦养成随手 merge 的习惯，提交历史就会慢慢变成一张蜘蛛网。每个 feature 分支开发完，往主干一 merge，自动生成一个 merge commit，多次并行开发之后，主干上的提交历史会出现大量分叉和汇合点。功能多了之后，你想理清“这个修复到底先合进哪个分支”，就得顺着网线去找。
这样说吧，merge 的特点是好心办坏事：它很安全，因为它完整保留了“真实发生过什么”，但代价是历史太密、太杂，人眼根本读不动。代码评审的时候，评审者如果还要在分叉图里来回跳，体验非常差。
2.2 rebase 的本质是“重演”，不是“合并”
rebase 的底层逻辑其实很简单：把当前分支上的一串提交，逐个“摘下来”，变成补丁一样的东西，再按顺序应用到你指定的目标分支的最新提交之后。
打个生活化的比方，merge 是几个人各写一段话，最后贴到一张纸上，保留每个人的字迹；rebase 是让同一个人把所有内容重新誊写一遍，誊写之后从头到尾看过去，整整齐齐，像是一个人连续写出来的。所以 rebase 之后，你的分支历史会变成一条直线，干净利落。
这个“重演”过程里有几个特点值得注意：
- 提交的 hash 值会变。因为提交的父节点变了，所以哪怕是同样的改动内容，提交 ID 也和之前完全不同。
- 不会产生额外的 merge commit。
- 目标分支不会发生任何改变。被“重写”的只是你当前所在的特性分支。
也就是说，rebase 本质上是在复制一次改动并换个时间点重新提交。这里的底层机制是 Git 的补丁应用机制：每个提交被转换成补丁，补丁依次应用到新基础上，如果某个补丁应用失败，Git 就会停下来让你处理冲突。
3. 第一次实操：用 git rebase 主干同步最新代码
3.1 为什么日常同步也要用 rebase 而不是 merge
开发过程中最常遇到的一个场景：你从主干拉了个功能分支，开发到一半，主干上别人推了几个新提交。这时候你的功能分支已经落后了，继续干活没问题，但等你提 PR 的时候，如果主干在你分支开发期间发生了较大变化，合并冲突的可能性会很高。
此时用 rebase 同步主干代码，不仅能保证功能分支始终基于最新的主干提交，还能让最终合并回主干时历史是一条直线。很多开源项目强制要求提交到主干前必须 rebase，理由就是这个——一条直线历史能最大程度减少合并冲突概率，也让日后的二分定位（git bisect）更方便。
3.2 实战：rebase 到最新主干的完整流程
假设当前你在 feature/login 分支上，主干是 main，同步命令如下：
bash复制# 先切到主干，拉最新代码
git checkout main
git pull origin main
# 切回自己的功能分支
git checkout feature/login
# 把功能分支的提交，重新应用到 main 的最新提交之后
git rebase main
执行 rebase 之后，如果没有任何冲突，你会看到类似输出：
bash复制Successfully rebased and updated refs/heads/feature/login.
这时再看一眼提交历史，你会发现 feature/login 的基点已经挪到了 main 的最新提交上，之前的所有提交记录还在，但 hash 全部变了。
如果中途有冲突，rebase 会停在你需要处理的那个提交那里，而不是让你一次面对所有问题。这是 rebase 和 merge 在冲突处理上一个很大的区别：
- merge 的冲突：一次性把两边的改动全部堆到你面前。
- rebase 的冲突：逐个提交处理，处理完一个，git rebase --continue 接着走下一个。
冲突处理的具体操