告别"话痨"提交记录！Git 压缩 Commit 实战指南，代码洁癖党狂喜

核心结论前置 ：提交历史乱成"屎山"，Code Review 时被同事疯狂吐槽？学会 git rebase -i，3 分钟把 N 个零散 commit 压缩成 1 个漂亮提交，谁用谁香！

一、为什么你的提交记录像"流水账"？

想象一下：你修个 BUG 改了 4 次，提交记录却是这样👇

makefile 复制代码

fix: 修复打包错误
fix: 忘了改配置
fix: 样式又崩了
fix: 终于可以了

这就像是把"起床→刷牙→洗脸→出门"拆成 4 条朋友圈发，刷屏还烦人。干净的提交历史就像工程师的脸面，回滚追溯时一目了然。话不多说，直接上干货！

二、核心拆解：交互式 Rebase 四步法

2.1 前置检查：确认你的"操作范围"

🔥 避坑第一步：先看清你要合并哪几个 commit，别手滑把别人的代码也 Squash 了。

bash 复制代码

# 查看最近 15 条提交，找准目标
git log -15 --pretty=format:"%h %s" --date=short

📌 建议：把 VS Code 设为默认编辑器，交互体验比 Vim 友好 100 倍（对，我就是在 diss Vim 的操作门槛 😏）：

bash 复制代码

git config --global core.editor "code --wait"

2.2 新建分支：给自己留条后路

这一点一定要注意！ 永远不要直接在 master 或 main 上玩 rebase，一旦翻车哭都来不及。

bash 复制代码

# 基于当前分支新建一个干净分支
git checkout -b feature/clean-history

类比：这就像做手术前先 Clone 一个备份，宁可多打一行命令，也别在生产线裸奔。

2.3 交互式 Rebase：把 4 个包塞进 1 个行李箱

假设你要压缩最近的 4 个 commit：

bash 复制代码

git rebase -i HEAD~4

此时会弹出编辑器，看到类似这样的列表：

plain 复制代码

pick a7adc57 fix:修复rsbuild打包错误
pick a789ee95 fix:deep 替换v-deep
pick 93a694fa fix:样式问题修复
pick db300adf fix css

使用vccode gitlense 更方便

核心操作 ：把后面 3 个 pick 改成 squash（或简写 s）：

plain 复制代码

pick a7adc57 fix:修复rsbuild打包错误
squash a789ee95 fix:deep 替换v-deep
squash 93a694fa fix:样式问题修复
squash db300adf fix css

gitlense 插件只需要勾选就行了

👉 人话解释 ：pick 是保留该提交，squash 是"把这个提交吞并进上一个"。就像把 4 个小包裹打包进 1 个快递箱，只付一次运费（生成一个 commit）。

2.4 编辑最终 Message：给包裹贴标签

保存退出后，Git 会再次打开编辑器让你合并提交信息。

❌ 别把 4 条原始 message 直接拼一起（那是垃圾堆）：

latex 复制代码

fix: 修复 rsbuild 迁移相关问题

- 修复打包配置错误（因升级 rsbuild 导致路径失效）
- 替换废弃的 /deep/ 为 v-deep
- 修复全局样式污染问题

✅ 高效技巧 ：用 - 列表清晰列出改动点，reviewer 一眼就能 get 到你的修改范围，省时间就是省生命！

三、避坑指南：这些雷区千万别踩 ⚠️

3.1 如果已经 Push 到远程了怎么办？

很多新手容易在这里翻车！如果这 4 个 commit 已经 push 到远程仓库，直接强推会覆盖别人的工作。

bash 复制代码

# 只能在个人分支或全新分支上执行！
git push origin feature/clean-history -f

毒舌提醒 ：千万别对 master、develop 这类公共分支强推，除非你想被全团队追杀 🔪。我踩过的坑，能绕电脑桌 3 圈，今天全告诉你们了。

3.2 遇到冲突怎么办？

如果 rebase 过程中提示 CONFLICT，别慌：

bash 复制代码

# 1. 手动解决冲突文件
git add .

# 2. 继续 rebase，不要额外 commit！
git rebase --continue

类比：这就像拼图时发现两片对不上，调整一下就继续，千万别按 git rebase --abort 直接跑路（除非你真的想放弃）。

四、进阶方案：更"硬核"的替代写法

如果你觉得交互式 rebase 太麻烦，或者需要更精细的控制，试试 cherry-pick + soft reset 组合拳：

bash 复制代码

# 1. 基于某个干净基点新建分支
git checkout -b clean-branch <base-commit-hash>

# 2. 把要合并的 4 个 commit 挑过来
git cherry-pick a7adc57 a789ee95 93a694fa db300adf

# 3. 回退到 4 个 commit 之前，但保留代码改动
git reset --soft HEAD~4

# 4. 重新提交，生成干净的单一 commit
git commit -m "fix: 修复 rsbuild 迁移相关问题"

📌 适用场景：需要挑选特定 commit 合并，而不是简单的"最近 4 个"。亲测有效，可直接套用！

五、总结一下 📝

核心命令 ：git rebase -i HEAD~N 是合并提交的王牌武器，YYDS！
绝对禁忌：不要在公共分支上强推，新建分支是最安全的选择。
Message 规范：合并后的提交信息要清晰，别让后人猜你的意图。

一句话升华：Git 提交历史不是垃圾桶，而是项目的"编年史"。学会管理 commit，不仅是对代码的尊重，更是对自己职业形象的负责。花 3 分钟整理历史，能省掉未来 3 小时的 debug 时间。

📚 拓展阅读：

我是海潮，专注前端工程化与 Git 最佳实践，关注我，解锁更多实用技术技巧，一起少踩坑、多提效 ✨