Git rebase 实战指南：从新手到线性历史构建者

1. 为什么我坚持在团队里教新人先学 rebase，而不是 merge？

Git rebase 这个命令，刚接触时很多人会本能地绕着走——觉得它“危险”“神秘”“容易搞丢代码”。我在带三届校招新人、参与过五个中型以上协作项目、亲手处理过 27 次因误操作导致的 rebase 后遗症之后，反而越来越笃定：rebase 不是高级技巧，而是现代 Git 协作的底层呼吸方式。它解决的从来不是“怎么把代码合进去”的问题，而是“怎么让别人读懂你写了什么”的问题。

你有没有遇到过这样的场景？

• Code Review 时，同事点开 PR，第一眼看到的不是你的功能逻辑，而是一堆Merge branch 'main' into feature/login的空洞提交；
• 回溯一个线上 Bug，git log 里像打翻的调色盘：A 分支 merge B，B 又 merge C，C 里还嵌着三个未命名的 hotfix；
• 新人 checkout 代码后执行git log --oneline --graph，直接被满屏的|\\和|\折线图劝退……

这些都不是 Git 的错，而是我们默认用 merge 构建历史时，把“技术动作”当成了“叙事逻辑”。rebase 的本质，是把“我做了什么”这件事，从时间轴上剥离出来，重新按逻辑顺序重排、打磨、封装——就像写文章要先列提纲、再删冗余、最后润色标题一样。它不改变功能，但彻底改变了代码的可读性、可追溯性和可信任度。

这篇文章不是教你怎么“用对”一个命令，而是带你重建对 Git 历史的理解：commit 不是时间戳，而是意图快照；分支不是轨道，而是草稿纸；rebase 不是魔法，而是编辑器里的 Ctrl+Z + Ctrl+Shift+I（格式化）+ Ctrl+Alt+M（合并段落）三连击。我会用真实项目中的截图级操作、手把手拆解每一步背后的决策依据，并告诉你哪些坑我踩过三次才记住——比如为什么git rebase -i HEAD~3里删掉某一行，实际会干掉两个 commit；为什么--force-with-lease不是保险绳，而是双刃剑；还有那个连资深工程师都常忽略的、决定 rebase 能否安全落地的关键前提：你的本地分支是否真的“干净”。

如果你现在还在用 merge 解决所有合并需求，或者只在教程里见过 rebase 却不敢在生产环境动它——这篇就是为你写的。它不假设你懂 reflog，也不跳过git add .这种基础动作。我们从一个刚 clone 完仓库、连.gitconfig都没配的新手视角出发，一步步走到能独立完成交互式变基、修复冲突、回滚失误的实战水平。

2. 核心设计逻辑：rebase 为什么不是 merge 的替代品，而是它的前置工序？

2.1 两种历史观的根本分歧：时间流 vs 意图流

很多教程一上来就对比 “rebase vs merge”，这本身就是一个误导性框架。真正该对比的，是merge-before-rebase和rebase-before-merge这两种工作流。让我用厨房做菜来类比：

• Merge-only 流程，就像把所有食材一股脑倒进锅里炒：葱姜蒜、肉片、青椒、酱油、糖、盐……全混在一起下锅。火候到了就出锅。结果是菜熟了，但你根本说不清哪口咸是因为酱油放早了，哪口柴是因为肉片没腌透——因为所有动作都被压缩在一个“炒”这个动作里。

• Rebase-before-merge 流程，则是先备菜：葱切末、姜切丝、肉片上浆、青椒切块、酱汁提前调好。每一步都独立完成、单独检查、命名清晰（比如“腌肉片 15 分钟”、“调酱汁：2:1:0.5”）。最后才把所有准备好的半成品，按逻辑顺序下锅：热油爆香葱姜 → 下肉片滑炒 → 加青椒翻匀 → 倒入酱汁收汁。每一步都可追溯、可复现、可优化。

Git 的 commit 就是你的“备菜步骤”。git merge是最后那个“下锅”动作；而git rebase，是你在下锅前，把所有备菜步骤重新整理、命名、排序、剔除无效动作的过程。它不替代 merge，而是让 merge 这个最终动作，变得有意义、可理解、可审查。

提示：当你在 PR 描述里写“本次合并包含登录页样式优化、密码强度校验增强、错误提示国际化”，这本质上就是在用自然语言描述一次成功的 rebase 成果——你已经把零散的开发过程，提炼成了有逻辑的交付单元。

2.2 为什么线性历史不是“美化”，而是协作刚需？

有人质疑：“非得线性吗？现实开发本来就是并行的啊！” 这个观点看似合理，实则混淆了“开发过程”和“交付成果”。Git 的核心价值之一，是让“谁在什么时候改了什么”这件事，具备法律级的可验证性。而 merge 提交（Merge branch 'main' into feature/x'）恰恰是这个链条上最模糊的一环——它只告诉你“发生了合并”，却不告诉你“合并时 main 分支到底是什么状态”。

举个真实案例：去年我们有个支付模块上线后出现偶发超时，排查时发现 bug 出现在feature/payment-v2分支的第 7 个 commit。但这个 commit 的 parent 是一个 merge 提交，而那个 merge 提交的两个 parent 分别指向：

• main分支的a1b2c3d（一个数据库连接池优化）
• feature/payment-v2分支的e4f5g6h（一个日志埋点增强）

问题来了：超时到底是a1b2c3d引入的？还是e4f5g6h引入的？还是两者交互导致的？由于 merge 提交抹去了这两个变更在合并时刻的真实上下文，我们花了 11 小时才用git bisect锁定到a1b2c3d的副作用。

而如果当时采用了 rebase-before-merge：

• feature/payment-v2的所有 commit 都是直接基于main的某个确定 commit（比如z9x8w7v）构建；
• 每个 commit 都有明确的、可测试的单一职责（如 “增加支付超时重试逻辑”、“统一异常码返回格式”）；
• git bisect可以直接在feature/payment-v2的线性序列上二分，3 分钟内定位到问题 commit。

线性历史的价值，不在于“看起来整齐”，而在于它把“不确定性”从历史中剥离，把“可验证性”刻进每个 commit 的 DNA 里。这不是洁癖，是工程底线。

2.3 rebasing 的三大安全边界：什么情况下绝对不能碰？

rebase 的风险被过度妖魔化，但它的危险区其实非常明确，只有三条红线：

1. 已推送至远程且他人正在基于其开发的分支
   这是最核心的禁忌。一旦你git push origin feature/x，这个分支的 commit hash 就成为团队协作的“公共契约”。你git rebase后强制推送，等于单方面撕毁契约——其他人的本地分支会瞬间变成“废墟”，他们git pull会得到一堆冲突，git log会显示重复或丢失的 commit。这不是技术问题，是协作伦理问题。

2. 未完成的、存在未提交变更的工作目录
   很多人以为git status显示 “nothing to commit” 就算干净，但忽略了git stash的存在。git rebase会尝试应用你的变更到新基底上，如果工作区有未暂存的修改（哪怕只是改了一行注释），rebase 会直接失败并报错error: cannot rebase: You have unstaged changes.。更隐蔽的是，有些 IDE（如 VS Code）会在后台自动保存文件，你以为没改，其实改了。

3. 没有确认目标分支最新状态的盲目操作
   git rebase main看似简单，但main是你本地的main，还是远程的origin/main？如果你本地main已经落后远程 50 个 commit，而你直接 rebase 到这个陈旧基底上，结果就是你的 feature 分支“穿越”到了过去，后续git push必然失败，且冲突极其难解。真正的安全操作是git rebase origin/main，前提是先git fetch origin。

这三条红线，不是凭空规定，而是从 Git 的对象模型（commit 是不可变的 SHA-1 哈希）和分布式协作本质中自然推导出的铁律。守住它们，rebase 就是你的瑞士军刀；越过它们，它就是一把没鞘的匕首。

3. 实操全流程拆解：从第一次git rebase到交互式精修

3.1 准备阶段：比git rebase更重要的三件事

在敲下git rebase之前，有三件必须完成的事，它们耗时可能不到 30 秒，但决定了整个 rebase 过程是丝滑还是灾难：

第一步：确认工作区绝对干净
执行git status，输出必须是：

On branch feature/user-profile nothing to commit, working tree clean

注意关键词是 “working tree clean”，不是 “nothing to commit”。前者意味着工作区和暂存区都无变更；后者只保证暂存区为空。如果看到modified: src/components/ProfileCard.vue，立刻处理：

• 若修改是临时调试，用git stash push -m "debug: temp console.log"存起来；
• 若修改是正式开发，用git add . && git commit -m "chore: add debug logs for profile load"提交；
• 若修改是误操作，用git checkout -- src/components/ProfileCard.vue丢弃。

注意：git stash不是万能保险。它只保存工作区和暂存区的差异，不保存 untracked 文件（如新创建的temp.js）。所以git status里如果有untracked files，必须手动处理或git clean -fd（慎用！）。

第二步：同步远程最新状态
不要相信你本地的main分支。执行：

git fetch origin

这条命令会下载所有远程分支的最新引用（refs），但不会修改你本地任何分支。执行后，你可以用git log --oneline origin/main查看远程 main 的最新 commit，用git log --oneline main对比本地 main 是否落后。如果落后，先git checkout main && git merge origin/main或git rebase origin/main更新本地 main（这是安全的，因为 main 通常不被其他人直接开发）。

第三步：创建 rebase 备份分支
这是老手和新手的分水岭。执行：

git branch backup/feature-user-profile-before-rebase

这个分支名包含backup/前缀和before-rebase后缀，是团队约定俗成的标记。它指向 rebase 开始前的精确状态。万一 rebase 中途出错或结果不符合预期，一句git reset --hard backup/feature-user-profile-before-rebase就能秒级回滚。我见过太多人因为省这 5 秒，花 2 小时重写代码。

3.2 基础 rebase：git rebase <target>的完整执行链

假设你的当前分支是feature/user-profile，目标是将其基于最新的origin/main。标准流程如下：

1. 切换到目标分支并确认状态

   git checkout feature/user-profile git status # 确保 clean git log --oneline -n 5 # 查看最近 5 个 commit，记下第一个（即 oldest）的 hash，比如 abc1234

2. 执行 rebase

   git rebase origin/main

   此时 Git 会：

   • 找出feature/user-profile分支独有的 commit（即不在origin/main中的那些）；
   • 将这些 commit 逐一“摘下”，按时间顺序排列；
   • 以origin/main的最新 commit 为新基底（new base），将第一个 commit 应用上去；
   • 如果应用成功，继续应用第二个，以此类推；
   • 如果某个 commit 应用时发生冲突，则暂停，等待你解决。

3. 冲突解决的标准动作流
   当出现冲突时，Git 会告诉你类似：

   Auto-merging src/views/UserProfile.vue CONFLICT (content): Merge conflict in src/views/UserProfile.vue error: could not apply def5678... feat: add avatar upload Resolve all conflicts manually, mark them as resolved with "git add/rm <conflicted_files>", then run "git rebase --continue". You can instead skip this commit: "git rebase --skip". To abort and get back to the state before "git rebase", run "git rebase --abort".

   此时：

   • 用编辑器打开src/views/UserProfile.vue，找到<<<<<<< HEAD和>>>>>>> def5678之间的冲突块；
   • 手动编辑，保留你需要的代码，删除冲突标记；
   • 保存文件；
   • 执行git add src/views/UserProfile.vue（必须add，不能只commit）；
   • 执行git rebase --continue。

   关键心得：git rebase --continue不是“继续 rebase”，而是“应用下一个 commit”。它会检查你add的文件是否已解决所有冲突，然后尝试应用队列中的下一个 commit。如果还有冲突，它会再次暂停。

4. 验证 rebase 结果
   rebase 成功后，立即执行：

   git log --oneline --graph --all

   你应该看到类似结构：

   * 9a8b7c6 (HEAD -> feature/user-profile) feat: add avatar upload * 5d4e3f2 feat: implement profile edit form * 1c2b3a4 fix: handle null user data * 7f8e9d0 (origin/main) chore: update dependencies * 2a1b0c9 feat: add dark mode toggle

   注意：feature/user-profile的所有 commit 都在origin/main的右侧（--graph显示的*符号），且没有|\\这样的分叉线。这证明线性历史已建立。

3.3 交互式 rebase：git rebase -i的七种武器

当你需要的不只是“移动”，而是“重塑”历史时，git rebase -i就是你的雕刻刀。它让你对一组 commit 进行原子级编辑。启动命令是：

git rebase -i HEAD~n

其中n是你要编辑的最近n个 commit。例如git rebase -i HEAD~3会打开一个编辑器，列出最近 3 个 commit（从最新到最旧）：

pick abc1234 feat: add loading spinner pick def5678 fix: prevent double submit on save pick ghi9012 chore: update README.md # Rebase 7f8e9d0..ghi9012 onto 7f8e9d0 (3 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's message # ...

七种常用操作详解：

1. reword（重写提交信息）
   适用场景：commit message 写得太随意，如fix bug、update code。
   操作：把pick abc1234 feat: add loading spinner改成reword abc1234 feat: add loading spinner，保存退出。Git 会打开编辑器让你重写 message，要求符合 Conventional Commits 规范，如feat(user-profile): add loading spinner with skeleton UI。

2. squash（合并提交）
   适用场景：连续几个小 commit 其实是一个逻辑单元，如git add .,git commit -m "WIP",git commit -m "fix lint",git commit -m "final version"。
   操作：保持第一个 commit 为pick，后面三个改为squash：

   pick abc1234 feat: add loading spinner squash def5678 fix: prevent double submit on save squash ghi9012 chore: update README.md

   保存退出后，Git 会合并这三个 commit，并打开编辑器让你编写新的 commit message。它会把原三个 message 拼接起来，你只需删掉不需要的，保留核心描述即可。

3. fixup（静默合并）
   与squash类似，但会自动丢弃被 fixup 的 commit 的 message，只保留第一个的。适合“补丁类”提交，如git commit -m "fix: typo in README"。操作同squash，只是把squash换成fixup。

4. drop（删除提交）
   适用场景：误提交了调试代码、敏感信息或已废弃的功能。
   操作：把对应行改成drop abc1234。注意：drop不是delete，它只是告诉 Git “跳过这个 commit”，不会影响工作区。但如果这个 commit 修改了文件，而后续 commit 依赖它，drop后可能导致编译失败或运行时错误，需自行验证。

5. edit（编辑提交内容）
   适用场景：想修改某个 commit 的代码，比如修复一个隐藏 bug，或补充测试。
   操作：把pick abc1234改成edit abc1234。Git 在应用到该 commit 时会暂停，此时你可以：

   • 修改文件；
   • git add .；
   • git commit --amend（注意是--amend，不是普通commit）；
   • git rebase --continue。

6. reorder（调整顺序）
   适用场景：commit 逻辑顺序混乱，如先写了测试，再写实现，最后又补了文档。
   操作：在编辑器里直接剪切粘贴行，改变它们的上下顺序。Git 会严格按照你排列的顺序重新应用 commit。注意：如果后一个 commit 依赖前一个 commit 的修改（如 A 创建了文件，B 修改了它），调换顺序会导致失败。

7. exec（执行自定义命令）
   适用场景：在每个 commit 应用后自动运行脚本，如npm test、yarn lint-staged。
   操作：在某行添加exec npm test。Git 会在应用完前一个 commit 后，执行该命令。如果命令失败（如测试不通过），rebase 会暂停，方便你介入。

实操心得：交互式 rebase 最大的陷阱，是忘记git add就直接git rebase --continue。Git 会认为“没有冲突”，直接应用下一个 commit，导致你的修改被丢弃。我的习惯是：每次修改完文件，立刻执行git status，确认修改已added，再--continue。

3.4 强制推送与--force-with-lease的正确姿势

rebase 后，你的本地分支指针已经移动，但远程分支还停留在旧位置。要同步，必须git push。但普通git push会失败，因为 Git 检测到“非快进式更新”（non-fast-forward update）。此时需要强制推送：

git push --force-with-lease origin feature/user-profile

为什么是--force-with-lease，而不是--force？

• --force是“无条件覆盖”，它会无视远程分支的当前状态，直接用你的本地值覆盖。如果同事在你 rebase 期间推送了新 commit，--force会直接把它删掉。
• --force-with-lease是“有条件覆盖”，它会先检查远程分支的当前值是否和你本地记录的值一致（即你git fetch时看到的值）。如果一致，才允许覆盖；如果不一致（说明别人推送了），则拒绝操作，并报错failed to push some refs to '...'。

这是一个关键的安全阀。它不能防止所有问题，但能拦截 90% 的误操作。使用前务必确保：

• 你刚刚执行过git fetch origin；
• 你没有长时间离线（超过团队平均推送频率）；
• 你清楚这个分支是否被他人共享。

如果--force-with-lease失败，不要硬上--force。先git fetch origin，然后git merge origin/feature/user-profile（如果对方改得少），或git rebase origin/feature/user-profile（如果对方改得多），再重新 rebase 和推送。

4. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

4.1 “rebase 后我的 commit 消失了！”——reflog 救命指南

这是最常被问的问题。原因几乎总是：git rebase过程中，你执行了git rebase --skip或git rebase --abort，但没意识到某些 commit 已被跳过或丢弃。Git 的reflog（引用日志）就是你的时光机，它记录了所有分支指针的每一次移动，无论是否被 rebase 影响。

恢复步骤：

1. 执行git reflog，你会看到类似输出：

   abc1234 HEAD@{0}: rebase (finish): returning to refs/heads/feature/user-profile def5678 HEAD@{1}: rebase (start): checkout origin/main ghi9012 HEAD@{2}: commit: feat: add avatar upload jkl3456 HEAD@{3}: commit: fix: prevent double submit ...

2. 找到你想恢复的 commit 的 hash（比如jkl3456）；
3. 执行git reset --hard jkl3456。

关键技巧：git reflog默认只显示 HEAD 的日志。如果你想查看特定分支的日志，用git reflog show feature/user-profile。另外，git fsck --lost-found可以找回所有“游离”的 commit 对象，但需要更深入的对象模型知识，日常用reflog足够。

4.2 “冲突解决后git rebase --continue还报错！”——隐藏的 staged/unstaged 状态

有时你明明解决了所有冲突文件，git add了，git status显示 clean，但git rebase --continue仍报错。最常见的原因是：你add的文件，其内容并未真正解决冲突。

Git 的冲突标记是<<<<<<<,=======,>>>>>>>。如果你只是删掉了这些标记，但没处理中间的代码逻辑（比如保留了两段互斥的 if 分支），Git 会认为冲突依然存在。git status显示both modified，但git diff可能不显示冲突标记，因为它已被你删掉。

排查方法：

• 执行git diff --cached（查看暂存区差异），如果输出中有<<<<<<<，说明你没删干净；
• 执行git ls-files -u，它会列出所有“未合并”（unmerged）的文件，即使git status没报错；
• 最可靠的方法：在解决冲突后，不急于--continue，先git commit（会自动创建一个 merge commit），然后git reset --soft HEAD~1，这样你能看到 rebase 试图应用的原始 commit 内容，再对比你的修改。

4.3 “为什么git rebase origin/main后，我的 commit 时间戳变了？”——时间戳的本质

rebase 后，commit 的author date（作者时间）保持不变，但committer date（提交者时间）会被更新为 rebase 当前时间。这是 Git 的设计使然：committer date记录的是“谁在什么时候把这个变更应用到当前分支”，它反映的是 rebase 这个动作的发生时间。

这会影响git log --since="2 weeks ago"这类基于时间的查询。如果你需要按原始开发时间筛选，用--author-date-order参数：

git log --oneline --author-date-order --since="2 weeks ago"

4.4 “团队要求必须用 merge，rebase 还有必要学吗？”——rebase 的不可替代价值

即使团队规范禁止git push --force，rebase 仍有不可替代的价值：

• 本地清理：在 push 前，用git rebase -i HEAD~5整理自己的 commit，把WIP、fix typo等琐碎提交squash掉，让 PR 历史干净；
• 实验性开发：在feature/experiment分支上，可以随意 rebase、edit、drop，因为没人依赖它；
• 学习 Git 模型：rebase 是理解 Git 对象模型（commit、tree、blob、ref）的最佳实践。它强迫你思考“什么是 commit 的 parent”，“什么是 branch pointer”。

我所在团队的规范是：feature/*分支允许 rebase，main、release/*禁止。这既保障了主干稳定，又赋予开发者重构历史的自由。

4.5 “rebase 后 CI/CD 流水线失败了！”——环境一致性陷阱

rebase 本身不改变代码功能，但可能触发 CI 失败。常见原因：

• 缓存污染：CI 环境可能缓存了 node_modules 或 build artifacts，而 rebase 后的 commit 顺序变化，导致某些postinstall脚本执行时机不同；
• 时间敏感测试：如果测试里用了new Date()并断言具体时间，rebase 后committer date变化，可能影响结果；
• 依赖版本漂移：rebase 过程中，如果package-lock.json被重新生成，而 CI 使用的是旧 lock 文件，就会失败。

解决方案：
在 rebase 后，CI 第一次运行前，手动执行一次npm ci（或yarn install --frozen-lockfile），确保本地环境与 CI 一致。把这一步写成 pre-commit hook，能避免 80% 的此类问题。

5. 工具链与配置优化：让 rebase 从“高危操作”变成“肌肉记忆”

5.1 配置 Git，让 rebase 更安全、更高效

在~/.gitconfig中添加以下配置，它们不是炫技，而是经过千次 rebase 验证的生产力加成：

[core] # 启用安全模式：rebase 时自动 stash 未提交变更 # 避免因忘记 stash 导致 rebase 失败 autosetuprebase = always [rebase] # 启用交互式 rebase 的默认编辑器（推荐 vim 或 VS Code） # 如果用 VS Code: editor = code --wait # 如果用 vim: editor = vim [pull] # 设置 pull 行为：默认使用 rebase 而非 merge # 这样 git pull 相当于 git fetch + git rebase origin/<branch> # 避免意外引入 merge commit rebase = true [alias] # 创建安全的 rebase 别名：自动 fetch + rebase + force-push # 使用时：git safe-rebase main safe-rebase = "!f() { git fetch origin && git rebase origin/$1 && git push --force-with-lease origin HEAD:$1; }; f" # 创建交互式 rebase 别名，自动打开最近 5 个 commit rb = "!f() { git rebase -i HEAD~${1:-5}; }; f"

5.2 IDE 集成：VS Code 中的 rebase 可视化

VS Code 的 GitLens 扩展（免费）能极大降低 rebase 认知门槛：

• 在Source Control视图中，右键点击任意 commit，选择Rebase onto...，它会自动列出所有可选基底分支；
• 冲突时，GitLens 的Changes视图会高亮显示冲突块，并提供Accept Current Change/Accept Incoming Change快捷按钮；
• git reflog历史可在Git Graph扩展中图形化展示，点击任意条目，右键Reset Branch to Commit即可一键回滚。

注意：IDE 的图形化操作虽便捷，但务必理解其背后执行的命令。我建议新手先用命令行完成 10 次 rebase，再用 IDE，否则容易陷入“点了但不知道点了什么”的困境。

5.3 日常工作流模板：一个可复制的 rebase 日常

这是我每天都在用的、经过 3 年验证的最小可行工作流：

# 1. 开始一天工作，先同步 git fetch origin # 2. 切换到 feature 分支 git checkout feature/user-profile # 3. 基于远程 main 更新（安全 rebase） git rebase origin/main # 4. 如果有冲突，解决后 git add . git rebase --continue # 5. 本地开发，提交多个小 commit git add . git commit -m "WIP: add profile header" # 6. 开发完成，整理历史（只整理自己写的） git rb 5 # 交互式 rebase 最近 5 个 # 7. 推送（自动 force-with-lease） git push --force-with-lease origin feature/user-profile # 8. 创建 PR，标题写明已 rebase # PR Description: "Rebased onto origin/main (commit 7f8e9d0). Clean linear history."

这个流程把 rebase 从“偶尔为之的冒险”，变成了“每日必做的晨间咖啡”。它不增加额外步骤，只是把原本分散的操作（fetch、rebase、push）串联成一条平滑的流水线。

6. 经验总结：rebase 的终极心法不是命令，而是思维

写完这篇超过 5000 字的实操指南，我想说的最后一点，不是技术细节，而是心态转变。

我最早抗拒 rebase，是因为把它当成一个“修改历史”的命令——仿佛在篡改过去。后来我才明白，rebase 修改的从来不是过去，而是未来。它修改的是“别人将如何理解你的过去”。每一个被squash的WIP提交，都是你送给未来同事的一份说明书；每一次reword，都是你对代码意图的一次郑重声明；而--force-with-lease的谨慎，是你对团队协作契约的无声尊重。

在我们团队，新人入职第一周的任务不是写代码，而是用git rebase -i重构自己第一天的 commit。有人把 7 个fix: xxx合并成 1 个feat: implement login flow；有人把git add .和git commit -m "save"删除，只留下chore: init project structure。这个过程很慢，但完成后，他们看git log的眼神变了——不再是“一堆哈希”，而是“一段故事”。

所以，别把 rebase 当成一个待掌握的命令。把它当作一种写作习惯：写代码是写，写 commit message 是写，写 rebase 脚本也是写。而所有写作的终极目的，不是为了让自己看得懂，而是为了让别人，在三年后的某个深夜，能快速抓住重点，少踩一个坑，多睡一小时。

这就是我坚持教新人先学 rebase 的全部理由。