我以前很害怕 git rebase。不是不会用，是不敢用——总怕把历史搞乱，总怕推不上去。
上个月我终于把它用顺了。这篇记下那次经历，以及我踩过的几个坑。
起因
一个小工具改了三天，提交记录长这样：
feat: 初版实现
fix: 修了个 bug
wip: 还没写完
fix: 又修了一个
style: 格式化
feat: 补了测试功能是对的，但历史完全没法看。如果半年后我回来，这些提交名一个都帮不上忙。
整理成故事
我用交互式 rebase 把这六条整理成了三条：
- 一条干净的 feat（实现 + 测试）。
- 一条 squash 掉的小修复。
- 一条独立的 refactor。
整理之后的提交记录，读起来像一个完整的故事，而不是一地鸡毛的工作日志。
坑一：只在本地 rebase
这是铁律。只对你还没推到远端的提交做 rebase。一旦推上去了，就不要再改那条线的历史——否则协作者会恨你。
如果你确实要改已推送的历史（比如清理自己的 feature 分支），务必先和协作者打招呼。
坑二：rebase 冲突
冲突不可怕，可怕的是你在冲突解决中途分心。我的做法是：
- 遇到冲突先
git status看清局面。 - 一次只解决一个文件，解决完就
git add+git rebase --continue。 - 实在乱了，
git rebase --abort重来，比硬撑划算。
坑三：忘记备份分支
rebase 之前，先建个备份分支。一条命令的事，能救你一次手滑。
git branch backup-before-rebase
# 然后放心地 git rebase -i HEAD~6结论
rebase 不是危险操作，是「有前提的操作」。前提就是：知道自己在改哪一段历史，并且那段历史还没被别人依赖。
在这两条之内，整理提交记录是一件很值得做的事。读自己的旧代码时，你会感谢自己的。