【Git技巧】git rebase -i 实战：优雅合并本地提交记录-CSDN博客

1. 为什么你需要学会合并本地提交？

不知道你有没有过这样的经历：写一个功能，修一个bug，或者重构一段代码，整个过程就像是在打地鼠，这里改一点，提交一次，那里修一下，又提交一次。最后一看提交历史，好家伙，七八条记录，名字还都差不多——“修复一个小问题”、“再修一下”、“最终修复”。这种提交历史，别说别人看了头疼，过两天你自己回头找某个关键改动点，都得像考古一样一条条翻。

我自己就经常干这事儿。尤其是在专注编码的时候，脑子里想的都是逻辑和实现，根本顾不上给提交起个好名字。往往是先 git add . 然后 git commit -m "fix" 就完事了，想着反正代码能跑就行。结果等到功能开发完，准备推送到远程仓库或者发起代码评审（Code Review）的时候，问题就来了。面对这一堆零碎的、语义模糊的提交，我都不好意思让别人看。更麻烦的是，如果这些提交里还夹杂着一些调试用的 console.log 或者临时的、后来又被我改回去的代码，那简直就是一场灾难。

这个时候，git rebase -i，特别是它的交互模式，就成了我的“后悔药”和“历史美化工具”。它不是什么高深莫测的黑魔法，而是一个实实在在能提升你代码提交质量和工作流整洁度的实用技巧。简单来说，它能让你重新编排、合并、修改甚至删除你本地的提交记录，而不用真的去改动任何一行业务代码。它的核心目标，就是把那些杂乱无章的“草稿式”提交，整理成一个个逻辑清晰、意图明确的“成品式”提交单元。

这不仅仅是面子工程。一个清晰的提交历史，意味着更好的可维护性。当项目需要回溯、排查问题（git bisect）或者生成更新日志（Changelog）时，一个原子性的、描述准确的提交比十个零碎的提交要有价值得多。对于团队协作来说，清晰的提交历史也是对队友的尊重，能让代码评审更高效。所以，别再让你的 Git 历史像一团乱麻了，花几分钟学会 git rebase -i，绝对是你 Git 技能树上最值得投资的一笔。

2. 交互式变基（git rebase -i）到底是什么？

光说“合并提交”可能有点抽象，我们得先搞明白 git rebase -i 到底在做什么。你可以把 Git 的提交历史想象成一串珍珠项链，每一颗珍珠就是一个提交（commit），它们按照时间顺序被一根线（指针）串起来。rebase 这个词，中文叫“变基”，听起来有点吓人，但其实它的动作就是“改变基础”。不过我们今天不深入讨论它和 merge 的区别，那是另一个大话题。

我们聚焦在 -i 这个参数上，它代表 interactive，即“交互式”。git rebase -i 就像给了你一个时光机和编辑台。它允许你回到过去（最近的 N 次提交），然后以一种交互的方式，重新“编辑”那段历史。注意，这里说的“编辑历史”通常只建议用于你本地、尚未推送到公共远程仓库的提交。因为一旦你改动了已经共享出去的历史，就会给协作者带来麻烦，需要用强制推送，这需要谨慎操作。

那么，这个“交互式编辑”能干什么呢？它提供了一个清单，列出了你指定范围内的所有提交。针对每一个提交，你可以发出不同的指令，比如：