Git rebase -i 其实没那么可怕
Git rebase -I is not that scary
作为初级开发者，我见过太多同事对 git rebase -i 望而生畏，甚至包括那些比我聪明得多的人。其实，这个命令只是打开一个文本文件让你编辑提交计划，并非不可逆的破坏性操作。你可以随时使用 git rebase --abort 回滚，而 git 的 reflog 机制更是能帮你找回一切。交互式变基不会销毁旧提交，只是创建新提交并移动指针。只要理解这一核心逻辑，并学会处理冲突，它将成为你整理分支历史、提升工作流的利器。别被恐惧束缚，试着去掌握它吧。
如果你不关心保持整洁的分支历史，我对你对待软件的认真程度表示怀疑。
HN 评论区
145- flyingcircus3
用了十多年 Git，我知道我对 rebase 的从容，以及确信自己不会犯下无法挽回的错误，都源于我知道随时可以 abort。只要没有被垃圾回收，只要我记住了那些哈希值，我总能找回那些孤立的提交，或者回退到 rebase 之前的那个提交。我确实可以回顾自己当年信心不足的日子，那时我错误地以为自己在走钢丝，一旦失误就会痛彻心扉、代价高昂，而且很容易走错路。而 abort 就是化解这一切的万能溶剂。
我确实还是会纠结下一步是该提交还是继续 rebase，因为这取决于你是在处理合并冲突，还是仅仅在编辑某个提交。但就算我搞错了，不小心把两个提交合并成了一个，abort 也能力挽狂澜。
- xg15
我所在团队广泛采用的一种工作流是：
1. 每个人都使用功能分支
2. 在代码审查之前，每个人都在 main 分支之上使用交互式 rebase 清理自己的分支
3. 所有合并操作都是基于刚在 main 上 rebase 过的代码
我觉得这套流程非常有效，既保持了历史记录的整洁，又维护了“每个提交只做一件事”的原则。
- mikemcquaid
Git rebase 本身一点也不可怕，可怕的是围绕它的狂热崇拜。我可能这辈子都看不到精心打理的 Git 历史带来的切实好处，但至少我看过几百篇博客和 HN 评论，都在痛斥“没有最干净的提交历史”是一种道德败坏。我内心那个愤世嫉俗的声音会说，人们只是过度认同自己最近对“自行车棚”（bikeshedding）的痴迷（就像那些长达 10 页的 vim 配置、定制键盘，或者其他承诺带来巨大却无法量化的性能提升的东西），但说实话，这大概只是关于代码的完全不同的思维模型。我至今还没遇到过需要查阅提交信息才能理解某段代码为何存在的情况，无论是代码本身还是它那再脏乱的历史。不过，我倒是期待有一天，我那位热衷于 rebase 的同事能用 git bisect 修复一个用其他方法根本无法高效解决的 bug。
- baq
你不需要打开 reflog，只需运行：
git reset --hard @{1}
就能在 rebase 之后“撤销”它。
- nixpulvis
我觉得如果你害怕 rebase，那你其实根本没懂 Git。