在我作为初级开发者的早期职业生涯中，遭遇的最令人震惊的事情之一就是围绕 git rebase -i 的恐惧。即使在一些我的同事中，他们在很多方面都比我聪明得多，许多开发者似乎都有这样的模式，惧怕这个命令。当你运行 git rebase -i HEAD~4 时，git 实际上干的是一件非常普通的事情：它打开一个文本文件。如果你在终端工作，并且没有更改你的 git 设置，执行 git config --global core.editor "_YOUR-EDITOR_" 是缓解你征服 vim 恐惧的一个好方法。选择 pick a1b2c3d 添加用户模型 pick e4f5g6h 修复用户模型中的拼写错误 pick i7j8k9l 添加登录端点 pick m0n1o2p WIP 调试登录 # 命令： # p, pick = 使用提交 # r, reword = 使用提交，但编辑提交信息 # s, squash = 使用提交，但合并到前一个提交中 # f, fixup = 像 "squash" 一样，但丢弃此提交的信息 # d, drop = 删除提交 值得注意的是，对于新 rebase 的用户来说，这只是一个计划，而不是一个动作。技术上没有发生任何事情，除了 rebase 已经开始。如果你改变主意，只需运行 git rebase --abort，重新开始或放弃（理想情况下是前者）。每一行都是一个指令，就是你要回放的提交开始了。你可以根据自己的喜好混合这些指令。 r a1b2c3d 添加用户模型 pick e4f5g6h 修复用户模型中的拼写错误 pick i7j8k9l 添加登录端点 d m0n1o2p WIP 调试登录 # 命令： # p, pick = 使用提交 # r, reword = 使用提交，但编辑提交信息 # s, squash = 使用提交，但合并到前一个提交中 # f, fixup = 像 "squash" 一样，但丢弃此提交的信息 # d, drop = 删除提交 这里发生了什么： 1. 在这个例子中，git 将在第一个提交上 '暂停'，允许你重新编写其信息。 2. d 或 drop 会完全删除 WIP 调试提交。这个相同的结果也可以通过简单地删除整行来实现。尽管我们改变了周围的提交，但中间的两个提交未被触碰。最终结果是总共 3 个提交，而不是 4 个。老实说，仅此而已。这并不是一件大事。如果你能内化这个例子的作用，交互式 rebase 会成为一个让你生活更轻松的工具，而不是更困难。 在那些喜欢否定交互式 rebase 目的的人中，还有一个共同的现象。虽然不想深入这些争论，我就直说：在我看来，如果你不在乎干净的分支历史（rebase 所带来的微小改进的一部分），那么我更倾向于对你在软件开发中的严肃性持怀疑态度。 “但如果我弄乱了怎么办？” 实际上这里很难丢失工作，有三个理由。你可以随时退出。正如上述的 git rebase --abort，你的分支将完全回到开始之前的状态。rebase 并不会摧毁提交——它会创建新的提交。这是关键的思维模型。rebase 并不会编辑你的旧提交；它创建新的提交，并将你的分支指针移到它们上面。旧的提交仍然存在于 git 的对象数据库中，尽管没有引用，但完整无损，直到垃圾回收发生前的一段时间。reflog 记得一切。这对我来说尤其重要，因为在我的第一个实习中，我删除了一个同事的分支历史，以为他们想要丢弃之前的提交。git 保留了你的分支所指向的每一个地方的日志： git reflog 找到 rebase 前的条目并恢复它： git reset --hard HEAD@{4} 整个 rebase 被撤销。这个安全网始终存在，这意味着一个失败的 rebase 最糟糕的结果是你在 reflog 中浏览几分钟。如果即使 reflog 也感觉过于艰巨（不过如果你已经读到这里，我希望你足够胜任去处理它），当然还有一种低技术的保险政策： git branch backup-before-rebase 现在，rebase 前的状态有了一个名字。如果出现任何问题，执行 git reset --hard backup-before-rebase，你就安全回家了。 冲突 有时，回放的提交会与先前的更改冲突（通常在重新排序或在更新的主干上 rebase 时）。git 会停止并字面上打印出指令：解决冲突，就像处理合并冲突一样，执行 git add 文件，然后 git rebase --continue。我认为这大概是最让人烦恼的。但冲突对于 git 来说并不是一个新概念。实际上，我会说在交互式 rebase 的上下文中，冲突实际上比在合并中更容易解决。这是因为你只处理一个提交，而不是整个分支。 义务警告就像在软件中的任何事情一样，你应该非常小心和努力地了解你正在做的事情，特别是像 rebase 这样的破坏性操作。是的，工作可以恢复，但这并不意味着你可以粗心大意。一个不错的通用经验法则