在处理补丁时，我希望提供一组干净的提交。因此，我经常发现自己在提交集干净并准备好合并之前反复重写历史记录。
在这个过程中，在收到审稿人的意见后，我会回去rebase -i修复我的代码，修复提交消息等。每次创建一个新的修订提交来替换之前的提交。先前的提交仍然存在，但不再是修订历史的一部分。
经过几次历史重写迭代后，我终于得到了一个干净的修订提交集，我可以推送或转换为补丁集。但现在我有时喜欢回顾一下我对一个或一组提交所做的更改历史，看看我在这个历史重写过程中做了什么。
我可以手动跟踪它——在某个地方写下我正在编辑的每个提交的提交哈希，然后再重写它。这样我可以回顾历史重写的历史，但这很乏味且容易出错。
有没有办法自动化这个，让 git 自己跟踪“二阶”历史——历史重写的历史？获取一个git log'提交，以显示历史上为生成该提交而执行的所有“修改”操作？
没有这样的事情：
提交的修改历史
因为提交本身实际上是不可更改的。历史重写不会更改旧的提交：相反，它会进行新的和改进的提交，您现在正在使用它而不是旧的提交。
在某种程度上，您可以做的是使用 reflogs 来查找各种名称（例如分支名称）用来声明为最近提交的哈希 ID，并使用它git rev-parse来查找他们现在声明的哈希 ID。然后使用git rev-list或git log查找可从当前分支提示访问的提交。
这有一些相当强的局限性。如果您总是用新的和改进的提交一对一地替换旧的和糟糕的提交，那么很容易说这branch~5是branch@{1}~5例如替换。但是，如果您的历史重写在重写期间添加或删除了提交，那么这里就没有简单的对应关系了。
根据您的历史重写工具，您可以做的另一件事是保留映射文件或数据库。如果你有一个映射说“旧的提交哈希 H = 新的和改进的哈希 H'”，对于每个替换的提交，以及诸如“旧哈希 H 被删除”或“新哈希 H 插入旧哈希 G 和我”在适当的时候，这会让你做你想做的事。
然而，总的来说，这是一个无法解决的问题。Git确实包含一个名为的东西git range-diff，它适用于问题的不同变体：它比较一些已知提交集的差异——你需要保存起点和终点哈希 ID——并将这些差异之间的差异描述为“旧补丁” 1 修改为新补丁 3”、“旧补丁 2 已删除”、“旧补丁 3 变为旧补丁 1”、“新补丁 2 插入”等等。