使用Git的版本控制已经成为每个现代开发者的默认工具。像commit,push, 和pull 这样的命令已经成为我们手指的肌肉记忆了。但相对来说，很少有开发者知道Git的 "更高级 "功能--以及这些功能有多大的价值。在这篇文章中，我们将探讨 "交互式重做"，它是 Git 中最强大的工具之一。
为什么交互式重述应该是每个开发者的工具带的一部分？
简而言之，毫不夸张地说，交互式回溯可以帮助你成为一个更好的开发者，因为它允许你在你的项目中创建一个干净和结构良好的提交历史。
为什么一个结构良好的提交历史很重要？试想一下相反的情况：一个难以阅读的提交历史，你根本不知道你的同事最近到底做了什么修改。在这样的项目中，越来越多的 "阴暗角落 "开始出现，而你只能了解你自己所做的小部分。
与此相对应的是一个干净的、结构良好的提交历史：它有助于使一个项目的代码库更易读，更容易理解。这是一个健康、持久的项目的基本要素。
交互式重构能为你做什么
交互式回溯帮助你优化和清理你的提交历史。它涵盖了许多不同的用例，其中一些允许你做到以下几点。
- 编辑一个旧的提交信息
- 删除一个提交
- 压扁/合并多个提交
- 重新排列提交的顺序
- 修复旧的提交
- 拆分/重开旧的提交以进行编辑
什么时候使用交互式重做（什么时候不使用！）？
和其他一些 Git 工具一样，交互式重做也是 "重写历史"。这意味着，当你用交互式重做操作一系列提交时，提交历史的这一部分将被重写：提交的SHA-1哈希值将被改变。可以说，它们是全新的提交对象。
这个事实要求我们遵守一个简单但重要的规则：不要对你已经在远程仓库与同事分享的提交使用交互式 rebase（或其他重写历史的工具）。相反，在合并到团队分支之前，用它来清理你自己的本地提交--比如你自己的某个特性分支。
交互式重写操作的基本机制
尽管交互式重定向有许多不同的用途，但基本工作流程总是相同的。一旦你牢牢理解了这个基本机制，交互式重构就会失去其 "复杂神秘 "的气息，成为你的工具带中一个有价值的、可利用的项目。
第1步：你应该从哪里开始工作？
你需要回答的第一个问题是："我想操作我的提交历史的哪一部分？"这告诉你应该从哪里开始你的交互式重构会话。让我们举个实际的例子，比如我们想编辑一条旧的提交信息（这就是我们一会儿要实际做的）。
我们的起始情况如下图所示，我们正在通过交互式 rebase 编辑一条旧的提交信息。
为了能够修改C2 中的提交信息，我们必须在其父级提交时开始我们的交互式 rebase 会话（如果你愿意，甚至在这之前）。在这个例子中，我们将使用C1 作为我们的交互式回溯会话的起点。
第二步：开始实际会话
开始实际的会话是非常简单的。
$ git rebase -i HEAD~3
我们使用带有-i 标志的git rebase 命令（以表明我们确实希望它是 "交互式 "的），并提供基本提交（我们在上面的第一步中提出的）。在这个例子中，我使用了HEAD~3 来指定 "HEAD 提交后面 3 个 "的提交。另外，我也可以提供一个特定的 SHA-1 哈希值。
第三步：告诉 Git 你想做什么
启动交互式重构会话后，你会看到一个编辑器窗口，其中 Git 列出了一系列的提交--从最新的提交，一直到（但不包括）你在步骤 1 中选择作为基础提交的那一个。
在这一步，有两件重要的事情要记住。
- **提交是按相反的顺序排列的。**最新的提交，也就是我们期望出现在顶部的提交，会出现在列表的底部。别担心：你的 Git 仓库已经很合适了。🥳 请记住，我们正在执行交互式重定向操作，这需要Git在操作结束时将提交内容从最旧的到最新的重新应用。
- 不要在这个编辑器窗口中做实际的修改尽管你可能迫不及待地想在这个编辑器窗口中简单地修改提交信息（毕竟这才是我们真正想做的......），但你必须表现出一定的耐心。在这里，我们只是要告诉 Git 我们想做什么-- 但不做实际的修改。我很快就会在实践中证明这一点
