我用了快十年的Git说实话日常翻车率最高的命令不是merge、不是cherry-pick而是rebase。原因也简单rebase会重写提交历史理解不到位的人一跑就乱一乱就慌一慌就容易硬着头皮强推然后就把远端搞废了。但你绕开它又不行因为但凡你待过一个稍微正规一点的团队review、合入、提测都要求一条干净线性的提交历史而这件事只有rebase能干得漂亮。这篇博文我会把rebase从原理到实操完整拆一遍重点覆盖三个最常见的场景把分支变基到主分支、交互式整理commit、以及处理rebase过程中必然撞上的冲突。同时会讲清楚rebase和merge的本质差别、rebase之后push被拒怎么办、amend怎么和rebase配合。内容主要面向已经能独立完成add、commit、push、pull这些基础操作的开发者如果你是刚学会git init的新手建议先翻一翻基础教程再回来看这篇。1. 先把rebase到底干了什么讲明白1.1 从一次真实的工作流冲突说起假设你从main分支切了一条feature分支然后埋头写了三天feature上多了5个commit。这时候同事合入了两个commit到main你想把main上的更新同步到feature里继续开发。你面前有两条路merge或者rebase。如果你的第一反应是执行git merge main那合并完之后feature分支上会多出一个merge commitGit史上会出现一个分叉的“蝴蝶结”看起来大概是这样* merge commit |\ | * main的提交 * | feature的提交 * | feature的提交 |/ * 公共祖先这种历史本身没错Git完全允许很多团队也这么干。但如果你长期在feature上merge main分支拓扑会越来越乱log里一堆merge commitreview的人看历史颗粒度时非常痛苦。而rebase做的事情是把feature上的每一个commit都“重新播放”到main的最新位置最后形成一条完全线性的提交链* feature第三次提交 * feature第二次提交 * feature第一次提交 * main最新的提交 * main之前的提交每次讲到这里我都会打个比方merge像是在一本杂志的中间夹了一页附录上面写着“我把别人的内容和我自己的内容缝在了一起”rebase则像是把你写的段落全部拆下来重新誊写到最新版本的文章后面让读者觉得这篇文章从头到尾就是一个人顺着写的。1.2 rebase和merge的本质区别很多人纠结rebase和merge到底选哪个其实两者解决的问题有重叠但代价完全不同。merge会保留“真实发生过的事情”——即分支是什么时候切的、两条线什么时候交汇的。rebase则把这些历史全部重写好像feature分支从来就长在main的最新提交后面。这两种决策面对同一个问题合入之后的历史是给谁看的给机器看两者都一样最终代码内容相同给人类看merge表达的是“并行开发最终合并”的过程rebase表达的是“任务串行完成”的结果。从实际团队协作来看有一条铁律必须记住绝不要对已经推送到远端并且别人已经拉取过的分支执行rebase。因为rebase之后commit的hash会全部改变别人本地基于旧hash的提交会直接迷失你强推上去他的本地就和远端裂成两半。这一点我要放在最前面说因为它值得你每一次操作前都默念一遍。1.3 rebase的三种常用形态一览rebase命令本身并不复杂核心就是三条变体git rebase base把当前分支的所有commit变基到目标分支或commit之上这是最基础的用法。git rebase -i base进入交互模式可以对commit做排序、合并、改写message等操作日常整理历史基本靠它。git rebase --onto 新起点 旧起点 分支把一个区间内的commit整体移植到另一个提交之上用来“搬移”一段提交历史。后面我会逐个场景展开但现在你先在脑子里留一个印象rebase的“搬运”动作本质上是“取commit的差异再重新提交一次”所以新的commit和旧的commit哪怕内容一模一样hash也不同。2. 环境准备从零把演示仓库搭起来2.1 Git安装与版本确认实操之前先确认你的环境是干净的别在演示过程中被工具版本差异干扰。这里以Linux/macOS的shell为例Windows用户建议用Git Bash而不是系统自带cmd否则部分命令行提示符和中文编码会给你添乱。安装Git的方法因系统而异macOS可以用homebrewWindows可以直接下载安装包Linux要看发行版。装完之后最重要的事情是确认版本$ git --version git version 2.39.2版本太老的话部分rebase特性可能缺失建议至少2.30以上。如果你还不知道Git怎么装搜索引擎里有大量图文教程我就不在这里重复写了。2.2 配置你的用户信息与基础偏好安装完成后第一件事是配置用户名和邮箱这步不做好commit依然能提交但历史里会显示一堆奇怪的默认值后续rebase看log时你会非常难受$ git config --global user.name Your Name $ git config --global user.email youexample.com接着建议顺手开启一些提升体验的选项$ git config --global pull.rebase true $ git config --global rebase.autoStash true $ git config --global --list这里解释一下两个关键配置的用途。pull.rebase true是说以后你执行git pull时本地如果有未推送的commitGit会优先用rebase而不是merge的方式来整合远端更新。rebase.autoStash true则是说当你有未提交的改动时rebase前Git会自动帮你暂存rebase完后再自动恢复省去你手动stash和pop的步骤。2.3 快速创建一份用于演示的仓库我们再准备一个最小可复现的仓库结构这样后面每个命令你都能亲手跑一遍看到和我一样的输出。$ mkdir rebase-demo cd rebase-demo $ git init $ echo line 1 demo.txt $ git add demo.txt $ git commit -m initial commit $ echo line 2 demo.txt $ git commit -am add line 2 $ git branch feature $ echo line 3 demo.txt $ git commit -am main: add line 3此时main上已经有3个提交但feature分支还停留在“add line 2”这个提交上。我们切到feature去新增一个提交然后模拟同事在main上继续开发$ git switch feature $ echo feature line 1 feature.txt $ git add feature.txt $ git commit -m feature: add feature file $ git switch main $ echo line 4 demo.txt $ git commit -am main: add line 4 $ git log --graph --oneline --all最后你应该能看到类似这样的输出* 0999a2b (main) main: add line 4 * 8e1f3c0 main: add line 3 | * a44b28f (feature) feature: add feature file |/ * 2b5319c add line 2 * 5d2a5a7 initial commit用git log --graph --all观察分叉是理解rebase前后变化最直观的方式。3. rebase核心场景实战拆解3.1 场景一把feature变基到最新main现在feature落后main两个commit同时自己多了一个commit。我们想在不产生merge commit的前提下把feature的提交重新放到main的最新位置之上。$ git switch feature $ git rebase main如果没有任何冲突Git会直接完成重放输出类似Successfully rebased and updated refs/heads/feature.再执行git log --graph --oneline --all你会看到feature分支的提交已经跑到main最新提交的后面并且概览是一条直线* a8f3b3c (feature) feature: add feature file * 0999a2b (main) main: add line 4 * 8e1f3c0 main: add line 3 * 2b5319c add line 2 * 5d2a5a7 initial commit这里有一个关键细节值得你停下来想想feature原本的commit hash是a44b28frebase之后变成了a8f3b3c。这就是我在前面强调的“rebase重写历史”的直接体现——commit本身的内容没有变但父提交变了hash自然跟着变。3.2 场景二交互式rebase整理混乱的提交这是rebase最强大的形态也是众多开发者爱上它的理由。假设你在feature分支上又新增了两个提交但其中一个是“fix typo”一个是“add missing semicolon”这种提交信息放在历史里对review的人毫无价值你完全可以把它们合并进前面的提交。$ git switch feature $ echo more line feature.txt $ git commit -am fix typo $ echo another line feature.txt $ git commit -am add missing semicolon $ git log --oneline --graph现在执行交互式rebase把最近三个提交全部打开$ git rebase -i HEAD~3Git会打开一个编辑器内容类似pick a8f3b3c feature: add feature file pick b2c9d10 fix typo pick c3e4f51 add missing semicolon # Rebase 0999a2b..c3e4f51 onto 0999a2b这里每一行的第一个单词是命令后面的hash是提交你可以用下面的关键词重新组织这些行pick保留该提交不修改内容。reword保留该提交但修改commit message。edit保留该提交但停下来允许你对内容做修改。squash把该提交合并到前一个提交中且合并后的message可以重新编辑。fixup把该提交合并到前一个提交中但直接采用前一个提交的message丢弃本提交的message。drop删除该提交。我们把“fix typo”和“add missing semicolon”压缩到第一个提交里只需要改成这样pick a8f3b3c feature: add feature file fixup b2c9d10 fix typo fixup c3e4f51 add missing semicolon保存退出后Git会用一种非常直观的“流式任务”方式处理先应用第一个提交然后把第二个提交的差异合并进来再合并第三个。最终git log --oneline --graph会变成* 9d6f7ab feature: add feature file * 0999a2b main: add line 4 * 8e1f3c0 main: add line 3三个提交被压成一个历史清爽干净。这个操作在开源社区被称为“squash your commits”几乎每个维护者都会在贡献指南里要求你这样做。注意交互式rebase里改动的行顺序就是最终提交的历史顺序。把“fixup”放在“pick”下面是让它作为前一个提交的补丁存在。如果你想把两个提交交换顺序直接交换两行的位置即可。3.3 场景三用amend修改最近一条提交热词榜里出现了“git commit --amend怎么使用”这个命令和rebase的关系非常紧密因为它们都是“改写历史”家族的一员。amend的作用是把当前暂存区的改动合并到最近一次commit里同时允许你重新编辑message。最常见的用法是提交之后发现漏了一个文件$ echo forgot this feature.txt $ git add feature.txt $ git commit --amend --no-edit--no-edit表示沿用原来的commit message只更新内容。如果你也想改message直接执行git commit --amendGit会打开编辑器让你改写。注意amend同样会改变commit的hash所以它也只适用于尚未推送的本地commit。不过amend有一个局限它只能改最近一条提交。如果你的修改目标是更早的历史那就必须借助rebase -i在目标提交的那一行把pick改成edit然后amend最后git rebase --continue。这套组合拳你最好记下来因为它是“修改任意历史提交”的标准姿势。3.4 场景四用--onto搬移一段提交--onto是rebase家族里最容易被忽略、但威力最大的成员。它的语义是把从一个提交点到另一个提交点之间的所有提交整体搬移到新的基底之上。语法$ git rebase --onto newbase oldbase branch举例说明你的feature分支历史是A - B - C其中B是一个错误的中间方案你希望彻底跳过B直接把C放到A之上。这时候可以执行$ git rebase --onto A B feature结果就是feature变成A - C。这种场景在日常开发中非常常见你提交了一个中间实验版本后来发现方案完全不可行但又不想让这个提交留在历史里用--onto可以精准切割。手动模拟一下我们先回到一个干净的分支状态创建一个新提交作为“要跳过的中间版本”然后执行上面的命令观察log即可。4. 冲突处理与常见问题排查4.1 冲突产生的原因与完整解决流程rebase过程中只要有两个commit修改了同一个文件的同一块区域Git就会停下来要求你人工裁决。这和你merge时遇到的冲突本质相同只是rebase的冲突会有“连续轰炸”的可能——因为你的每个commit都要重新应用一遍如果中间有多个commit都碰到冲突你就要反复解决。假设我们让feature和main同时修改demo.txt然后执行git rebase main你会看到Auto-merging demo.txt CONFLICT (content): Merge conflict in demo.txt error: could not apply a44b28f... feature: add feature file hint: Resolve all conflicts manually, mark them as resolved with git add/rm conflicted files, then run git rebase --continue.这行hint写得非常清楚Git已经告诉你了完整流程。实际操作分四步打开冲突文件搜索、、标记手工修改成想要的内容。git add这个文件把解决结果标记为已暂存。git rebase --continue让Git继续应用下一个commit。如果还有冲突就重复前两步直到rebase完成为止。如果过程中发现思路全乱了或者冲突太复杂不打算继续可以随时执行git rebase --abortGit会把分支恢复到rebase之前的状态当作什么都没发生。还有一个git rebase --skip它的意思是“放弃当前这个commit的改动继续下一个”只有在确认当前commit完全不需要保留时才应该用它。4.2 push被拒绝后的正确姿势这是rebase新手提问率最高的问题。现象是你对一个已经推送到远端的分支做了rebase然后git pushGit直接拒绝提示! [rejected] feature - feature (non-fast-forward) hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart.原因是远端feature分支的提交历史和本地已经分叉了。由于rebase重写了commit本地的feature不再是远端feature的“后代”Git默认不允许这种会覆盖远端历史的推送。此时你面临两个选择如果这个分支只有你一个人在开发且还没有被别人拉取过可以安全地强制推送git push --force-with-lease。如果这个分支别人已经拉取过或者你无法确认远端分支的使用情况那就不要强推老老实实用git merge main来同步主干放弃线性历史。这里我要重点推荐--force-with-lease而不是--force。--force是无条件地覆盖远端分支而--force-with-lease在推送之前会检查远端分支是否和你上次拉取时的状态一致如果不一致说明有人动了远端推送会被拒绝。这个参数是我血的教训换来的——它能在你误伤别人的提交之前拦你一把。4.3 rebase与amend配合的完整思路这两个命令经常一起出现因为它们一个负责改“最近的提交”一个负责改“较早的提交”。两者配合使用时有一个容易踩的坑如果你已经推送过分支然后执行了amend修改了最近一次提交下次push同样会被拒绝解决方式和4.2一模一样——--force-with-lease。请记住这条判断顺序先看这个commit有没有推送到远端再看有没有其他人拉取过。如果答案是“没推送”或“推送了但只有我自己在用”那么amend和rebase随便用只要答案变成“别人也拉取了”历史就不能再改。4.4 常见问题速查表这一节我把实际工作中遇到的高频问题汇总成一张表格方便你日后翻看。报错或现象原因分析解决办法fatal: not a git repository当前目录不是Git仓库或没有正确切换路径检查pwd确认在仓库根目录或子目录内does not have a commit checked out分支名写错rebase目标不存在git branch -a查看全部分支名error: cannot rebase: You have unstaged changes有未提交的改动rebase会覆盖这些内容先git stashrebase完成后git stash popCONFLICT (content)两个commit修改了同一区域的代码手工解决文件冲突后add并continuenon-fast-forward推送被拒本地历史与远端历史分叉用--force-with-lease强制推送或改用merge解决冲突时误用了git commitrebase冲突解决后不需要执行commit直接git add后git rebase --continuegit rebase --abort后代码丢失abort只回退rebase过程本身不会删除你原本的提交检查git reflog可以找回原提交4.5 从reflog里捞回被rebase折腾掉的提交rebase会改写历史但并不意味着你的旧提交就会被立即物理删除。Git有一份名为reflog的本地日志记录了你所有分支引用的历史移动轨迹。只要仓库还在即便你rebase到一半abort或者把分支重置到了错误位置旧提交通常都还躺在对象数据库里。操作方式$ git reflog输出结果类似3b89127 HEAD{0}: rebase finished: refs/heads/feature onto 0999a2b 3f88456 HEAD{1}: rebase: fixup! add missing semicolon 9d6f7ab HEAD{2}: rebase: fixup! fix typo a44b28f HEAD{3}: rebase: checkout main f3e5c7b HEAD{4}: commit: feature: add feature file如果你发现自己把分支搞坏了想要回到rebase之前的某个状态只需要找到对应提交的hash然后$ git reset --hard a44b28f这个恢复手法救过我好多次。所以如果你在rebase过程中犹豫不决先别慌着abort看看reflog再决定也不迟。5. 结合工作流谈几点实际体会我做code review时最想看到的就是一条干净的提交线每个commit只做一件事message准确描述改动意图没有“fix typo”满天飞。这并不代表历史要求绝对线性而是说提交历史应该像一封写得工整的信而不是一张随手记满草稿的废纸。rebase就是用来帮你整理这张废纸的橡皮和剪刀。基于这个目标我建议你在本地开发时可以频繁地使用rebase和amend来整理自己的提交但有一个界线要守住本地提交可以反复揉捏一旦push到远端并进入共享分支就不要再动了。如果确实需要维护一个干净历史可以在push之前自己rebase一遍然后在PR描述里写清楚你的提交组织方式。另外提交粒度这件事也值得多说一句。很多新人喜欢把所有改动堆到一个commit里一旦review发现问题就无法单独回滚只能整个commit一起撤销。更好的做法是开发过程中用多个有意义的commit记录进度提交到PR之前再用rebase -i和squash把逻辑相关的commit归并整理。这样你的工作记录有迹可循最终合入主干的又只剩简洁的历史。最后分享一个我日常最常用的习惯在执行任何会改变历史的rebase命令之前先给当前分支打个保险牌$ git branch backup-feature $ git rebase -i HEAD~5一旦过程出问题直接git reset --hard backup-feature就能回到操作前。这个习惯听起来很笨但实际上它比任何高端的reflog操作都稳而且几乎不需要额外成本。等你操作越来越熟练、rebase成了本能动作之后自然就不需要每次都备份了可这个兜底的动作我到现在也没打算丢掉。
