git rebase -i为何修改提交哈希？仅压缩部分提交全量哈希变更解惑

这是个特别典型的Git疑惑，很多人第一次碰到都会懵——明明只改了最后两个提交，怎么前面十几条提交的哈希全变了？咱们一步步拆解原因，再给你实用的解决办法。

为什么18个未修改的提交哈希也会变？ #

Git的提交哈希（SHA-1值）是由提交的完整元数据计算出来的，不止包含提交内容和父提交哈希，还有这些关键项：

• 作者姓名、邮箱及作者时间戳（提交最初创建的时间）
• 提交者姓名、邮箱及提交者时间戳（提交被最终记录到仓库的时间）
• 提交说明文本

当你执行git rebase -i HEAD~20时，Git会从HEAD~20开始，把这20个提交逐个"重新应用"一遍，生成全新的提交对象。这就带来两个必然改变哈希的核心因素：

1. 提交者时间戳被更新：默认情况下，rebase生成的新提交，提交者时间戳会变成你执行rebase的当前时间——哪怕你没修改这个提交的内容和父提交，这个时间戳的变化就足以让哈希值彻底改变。
2. 父提交哈希的连锁反应：哪怕你只修改最后两个提交，前面的提交链也会被打破。比如Git重新生成第一个提交（HEAD~20）时，它的哈希因为时间戳变了而更新；那下一个提交（原本的HEAD~19）的父哈希就变成了这个新的HEAD~20哈希，哪怕内容没改，这个提交的哈希也会跟着变；以此类推，整个20个提交的哈希都会因为父哈希的连锁变化全部更新。

你猜测的时间戳确实是原因之一，但父哈希的连锁反应才是让所有提交哈希全变的关键。

如何避免不必要的哈希变更？ #

根据你的需求，有两个更精准的解决方案：

1. 只针对目标提交范围执行rebase #

如果你只需要压缩最后两个提交，完全没必要处理前面20个提交。直接执行：

git rebase -i HEAD~2

这样Git只会重新生成最后两个提交，前面的所有提交都不会被触碰，哈希自然保持不变。

2. 让提交者时间戳沿用作者时间戳 #

如果你确实需要处理大范围的提交，但希望保留原来的提交时间（避免无意义的哈希变更），可以使用--committer-date-is-author-date参数：

git rebase -i --committer-date-is-author-date HEAD~20

这个参数会让rebase生成的新提交，提交者时间戳和作者时间戳保持一致，而不是用当前时间。这样一来，那些内容和父提交都没修改的提交，元数据和原提交几乎一致，哈希值就不会改变了（除非你主动修改了提交说明或内容）。

需要注意的是：如果你的rebase操作修改了某个提交的内容或父提交链，那这个提交及其之后的所有提交哈希还是会改变——这是Git的特性，因为提交哈希必须准确反映提交的所有状态。

内容的提问来源于stack exchange，提问作者Ákos Vandra-Meyer