说实话，咱们Zuo开发的，谁还没个“手滑”或者“强迫症”发作的时候？尤其是在赶项目进度或者修Bug修得热火朝天的时候，那个 git commit 指令敲得比谁dou快。结果呢？等到要提代码合并请求的时候，回头一kan自己的提交历史，心里顿时“咯噔”一下——满屏的“geng新了readme”、“修复空格”、“ geng新readme”……这乱七八糟的记录，别说代码审查的同事kan着头疼，就连自己过两天再kandou觉得脸红。

这时候，拯救咱们于水火的神器就登场了——没错，就是那个听起来有点吓人，但用起来真香的 git rebase。今天咱们不聊那些枯燥的理论，直接来点实战干货，kankan怎么用 git rebase -i 这把“手术刀”，把那些零碎的提交像变魔术一样整整齐齐地合并成一个。

为什么我们需要合并提交？

在深入命令之前，咱们得先明白“为什么要这么Zuo”。hen多新手朋友觉得，代码提交上去了不就行了吗？只要Neng跑就行，管它历史记录长什么样。这种想法在个人项目里或许还行，但在团队协作中，简直就是“灾难现场”。

想象一下你的同事正在Review你的代码，结果他需要在一个功Neng点和另一个Bugfix之间来回跳转，只因为你的提交记录太碎了。或者，当你需要把开发分支的代码 cherry-pick 到发布分支时你发现自己不得不搬运十几个零碎的补丁，这得多崩溃？

所以保持提交历史的清晰和整洁，不仅是为了美观，geng是为了团队协作的效率。每一个提交，dou应该是逻辑完整、意义明确的一个“原子操作”。这就是我们要把多个相近的提交合并成一个的根本原因。

准备工作：kan清你的历史

在动刀之前，咱们得先kankan“病灶”在哪里。打开你的终端，进入项目目录，输入那个咱们Zui熟悉的命令：

git log --oneline

这个命令会列出Zui近的提交记录，每一条只显示哈希值和提交信息，简洁明了。假设你现在在 dev 分支上，输出大概是这样的：

a1b2c3d  修复了登录页面的样式问题
e5f6g7h 添加了登录按钮的点击事件
i8j9k0l geng新了README文档
m1n2o3p 初始化了项目结构

kan着前三条，是不是觉得它们其实dou是在Zuo“登录功Neng”这件事？Ru果Neng把它们揉成一个提交，信息改成“完成登录功Neng开发”，那世界是不是瞬间美好了？好，目标有了咱们开始动手。

核心步骤：启动交互式变基

这里的主角登场了：git rebase -i。这里的 -i 就是 interactive的缩写，意味着 Git 会把控制权交给你，让你自己决定怎么处理这些提交。

Ru果你想合并Zui近的 N 个提交，比如咱们刚才想合并Zui近3条，那就运行：

git rebase -i HEAD~3

这里的 HEAD~3 表示“从当前 HEAD 往前数3个提交”。注意，这个范围是包含 HEAD 的。或者，你也Ke以指定具体的提交哈希值，比如你想把从某个特定提交之后的所有改动dou合并起来就Ke以用那个提交的 ID。不过要注意，Ru果你想合并到目标提交，你指定的 ID 必须是目标之前的那个，这一点新手特别容易搞混，切记切记！

进入 Vim 编辑器：选择你的操作

敲下回车后你的终端会突然变身，弹出一个kan起来有点复古的 Vim 编辑器界面。别慌，这就是咱们施展魔法的地方。你会kan到类似下面这样的内容：

pick a1b2c3d 修复了登录页面的样式问题
pick e5f6g7h 添加了登录按钮的点击事件
pick i8j9k0l geng新了README文档
# Rebase commands...

这里的每一行代表一个提交，前面的 pick 字样是 Git 默认的操作指令，意思是“保留这个提交”。现在咱们要Zuo的就是把后面的指令改一改。

认识几个关键指令

在 Vim 里Git 给咱们提供了好几个指令，咱们今天重点掌握这几个就够用了：

pick保留该提交，不Zuo改动。

squash这个是今天的主角。意思是“应用这个补丁，但把它和前面的提交合并”。

fixup和 squash 类似，也是合并，但它会丢弃掉当前这个提交的日志信息，只保留代码改动。适合那些“ typo 修复”之类的无意义提交。

reword保留提交，但允许你修改提交信息。

实战操作：修改指令

回到咱们的例子。咱们想把这三个提交合并成一个。通常的Zuo法是保留第一个提交，把后面两个改成 squash 或者 fixup。

在 Vim 编辑器中，按一下 i 键进入插入模式，把内容修改成这样：

pick a1b2c3d 修复了登录页面的样式问题
s e5f6g7h 添加了登录按钮的点击事件
s i8j9k0l geng新了README文档

或者，Ru果你觉得后面那两个提交信息没啥保留价值，想省点事，也Ke以用 fixup

pick a1b2c3d 修复了登录页面的样式问题
f e5f6g7h 添加了登录按钮的点击事件
f i8j9k0l geng新了README文档

改完之后按 Esc 键退出插入模式，然后输入 :wq 并回车保存退出。这时候，Git 就会开始解析你刚才写的指令，开始重新应用这些补丁。

合并提交信息：给新家起个名字

Ru果你刚才用的是 squash，Git 会 弹出一个 Vim 窗口。这次是让你编辑合并后的提交信息。你会发现，窗口里列出了之前所有被合并的提交信息：

# This is a combination of 3 commits.
# 修复了登录页面的样式问题
# 添加了登录按钮的点击事件
# geng新了README文档

这时候，你Ke以把那些乱七八糟的旧信息dou删掉，只写一句Zui精炼、ZuiNeng概括这次改动的信息，比如：

完成登录功Neng开发及文档geng新

:wq 保存退出。恭喜你！大功告成。

Ru果你刚才用的是 fixup，Git 就不会弹这个窗口，它会直接用第一个提交的信息作为Zui终信息，默默地把后面的合并进来非常干脆。

验证成果：享受整洁的快感

现在咱们再来kankan提交历史。输入 git log --oneline，你会惊喜地发现：

x9y8z7w  完成登录功Neng开发及文档geng新
m1n2o3p 初始化了项目结构

kan！之前那三个啰嗦的提交不见了取而代之的是一条干净利落的记录。是不是感觉整个人dou清爽了？这时候你再把这个分支推送到远程，或者进行 git cherry-pick，dou会变得异常轻松。

进阶技巧：处理geng复杂的情况

当然实际开发中遇到的情况可Neng比这复杂得多。有时候，咱们可Neng需要合并几十个提交，或者需要在合并的过程中修改某些代码。

比如我之前遇到过一个需求，开发过程中因为各种原因，本地提交了足足36个 commit！这要是直接合并，光挑拣dou得半天。这时候，咱们依然Ke以用同样的方法：

git rebase -i HEAD~36

虽然 Vim 里会列出长长的清单，但操作逻辑是一样的。你Ke以把大部分琐碎的 fix 提交标记为 fixup，只保留几个关键的里程碑式提交作为 pick 或 reword。

另外关于 reword这个指令，有时候咱们不想合并提交，只是想改一下之前写错的提交信息，这时候就Ke以把对应行的 pick 改成 r。Git 在执行到这一步时会停下来让你编辑信息，改完继续走流程即可。

重要提醒：Rebase 的“双刃剑”属性

说了这么多 git rebase 的好处，Zui后必须得泼一盆冷水，提醒大家注意安全。Rebase 虽然强大，但它本质上是在重写历史。

什么意思呢？当你执行 rebase 后那些被合并的提交的哈希值dou会发生变化。对于你本地的私人分支来说这完全没问题。但是千万不要在Yi经推送到远程公共仓库的提交上执行 rebase！

为什么？因为Ru果你的同事Yi经基于你的旧提交进行了开发，你突然把历史改了他们的本地仓库就会和远程仓库“脱节”，到时候同步代码时就会出现一堆莫名其妙的冲突，甚至可Neng丢失代码。这可是会被团队小伙伴“打”的！

所以git rebase Zui好只用于整理尚未推送的本地提交，或者你自己一个人的特性分支。在合并到主分支之前，把历史整理得漂漂亮亮的，然后再用 git merge合进去，这才是Zui佳实践。

总而言之，git rebase -i 是每一个追求卓越的开发者dou应该掌握的神技。它不仅Neng帮咱们把杂乱无章的提交历史梳理得井井有条，还Neng让代码审查变得高效愉快。

虽然刚开始接触 Vim 编辑器和这些指令时可Neng会觉得有点别扭，甚至有点“反人类”，但只要多练习几次你就会爱上这种掌控一切的感觉。下次当你发现自己又提交了一堆“临时补丁”时别犹豫，祭出 git rebase -i，把它们统统压合成一个完美的提交吧！相信我，你的未来自己会感谢你的。

---