• 提交是记录你的工作的历史记录，并且保证你所做的更改是神圣不可侵犯的，但提交自身不是一成不变的。Git提供了几个工具和命令，专门用来修改完善版本库中的提交。

• 有很多理由让你去修改或返工某个提交或整个提交序列：
  • 可以在某个问题变为遗留问题之前修复它。
  • 可以将大而全面的变更分解为一系列小而专的提交。相反，也可以将一些小的变更组合成一个更大的提交。
  • 可以合并反馈评论和建议。
  • 可以在不破坏构建需求的情况下重新排列提交序列。
  • 可以将提交调整为一个更合乎逻辑的序列。
  • 可以删除意外提交的调试代码。

• 当涉及操纵开发历史的时候，主要是更改历史的哲学（Philosophy of Altering History)思想：现实历史的哲学和说教式现实历史
  • 现实历史的哲学：每个提交都保留，并且不能修改任何内容。根据这种思想衍生出来一种称为细粒度的现实历史的思想，即你要尽快提交每个修改，以确保每步都为后人保存。
  • 说教式现实历史：只有在方便且适宜的时候才提交最好的工作成果。
  • “理想主义”的历史：给你一个改变历史的机会——可以清理一些不好的中间设计决策或者把提交重新排列成更合乎逻辑的流程。

• 作为开发人员，你可能会发现完整的、细粒度的现实历史很有价值，因为它可以提供关于一些好或坏的主意发展过程的考古细节。一个完整的叙述可以让你深入了解bug的起因，抑或是细致阐明bug是如何修复的。事实上，对历史的分析可以让你深入了解开发人员或团队开发的工作细节，以及如何改善开发过程。
• 如果被修订过的历史删除了许多中间步骤，那么很多细节也可能就丢失了。开发者仅凭直觉就想到这么好的解决方案吗？还是经过了几轮迭代或精化？出现bug的根本原因是什么?如果提交历史中不能保留这些中间步骤，那么上述问题的答案可能将不得而知。
• 如果有个干净的历史记录，显示出定义良好的步骤，每个步骤都有逻辑清晰的前进过程，那这是多令人愉悦啊。而且，没有必要担心版本库历史记录中变化莫测的崩溃或次优的步骤。另外，其他开发人员通过阅读历史也可以学习到更好的开发技术和风格。

• 没有信息丢失的详细现实历史是最佳方法吗？或者干净的历史更好点？也许开发的中间过程是必要的。或者使用Git分支，也许可以在同一个版本库里同时包含细粒度的现实历史和理想化的历史。
• Git让你有能力在发布或提交到公共记录之前清理真实历史记录，并把它变成更理想化的或更简洁的历史记录。无论你选择怎么做，是保持详细记录不改变，还是选择某些中间过程，这完全取决于你和你的项目策略。

1、修改历史记录的注意事项

• 只要没有其他开发人员已经获得了你的版本库的副本，你就可以自由地修改和完善版本库提交历史记录。或者更精确一点，只要没人有版本库中某个分支的副本，你就可以修改该分支。如果一个分支已经公开了，并且可能已经存在于其他版本库中了，那你就不应该修改该分支的任何内容。

• 已发布的历史记录：已经共享给其他程序员的历史记录。不应该修改任何内容。
• 未发布的历史记录：没有共享给其他程序员的历史记录。可以重新排序、合并、删除甚至添加新提交。

• (1)假设你已经在master分支上工作了一段时间，进行了A~D四次提交，并且将这四个提交共享给其他程序员了。如图10-1所示。

• (2)一段时间之后，你在相同分支上产生了W~Z之间未发布的新提交。如图10-2所示。

• (3)在这种情况下，不能修改W之前的提交。但是，直到你重新发布master分支前，你可以修改提交W~Z，可以进行的操作有重新排序、合并、删除甚至添加新提交。
  • 例如，将提交X与Y合并成一个新提交，修改提交W产生一个新提交W'，移动提交Z到历史记录中更早的位置，还引入了一个新提交P。如图10-3所示。

2、使用git reset

1

#                                                                                                                           #