因为提交是不可变的。它的标识符，一个散列，取决于它的内容。更改内容 - 哈希更改，您将获得具有不同 ID的提交，但来自与当前提交相同的基础。

抱怨这个就像抱怨如果你在 5 上再加一个，你会得到一个完全不同的数字。:)

git commit --amend“忘记”当前提交，采用旧提交所基于的相同提交*，在其之上进行新提交*，同时考虑索引**的内容并将分支推送到结果结果。现有提交没有真正的变化。

其实很好。这消除了“某处意外发生变化”系列中的惊喜。对于版本控制系统，这是一个很好的特性。

因此，有一种做法：

永远不要commit --amend对已发布的提交做***

...否则你可以看到它会导致什么。

然而，该系统并不完美，最近关于Git 内部使用的 SHA-1 黑客攻击的消息引起了人们的怀疑，即是否有可能在 Git 不怀疑的情况下用一些剩余的更改来伪造哈希。

现在担心这个还为时过早，除了最大的 IT 巨头。在实践中，还使用了数据的长度，这使得很难按数量级选择碰撞。这已经很不容易了，实际上是不现实的：已知的黑客攻击案例需要大约 6500 个 CPU 年。你需要一个很好的理由为每个这样的操作分配这么多的资源。

* 或多个提交，如果合并提交被替换

** 那里，如果有的话，所有跟踪的文件，而不仅仅是更改的文件，所以如果分支突然开始指向另一个提交，与索引中的状态进行比较（因此，计算提交的更改）仍然有效正确地

*** 带有一堆“如果”：比方说，如果这不是您的个人分支机构，除了您之外没有人会指望它，如果是，那是您自己的错；一个很好的例子是他们各种 Git*-flow 的功能分支。

提交是一个不可变（immutable）对象。因此，所有“编辑”和“移动”提交的操作实际上都会创建新的操作——但与之前的操作非常相似。

我们的承诺是由什么组成的？

理论上

让我们仔细看看提交。每次提交都会保存以下数据：

• 保存在此提交中的工作区内容的链接。内容本身被编码在另一个对象中，并且在提交中 - 只是对该对象的引用。
• 链接到父（先前）提交。存储库中的第一个提交没有父项，合并提交有两个或多个父项。
• 更改的作者和更改的保存日期。
• 提交的作者和保存提交的日期。当一个人的提交由另一个人提交时，可能与更改的作者不同 rebase。
• 该消息是文本评论。

实践中

您可以使用命令查看提交的内容git cat-file commit <ссылка>。在这个例子# комментарии中，是我添加的，剩下的就是命令的输出。

git cat-file commit HEAD

# ссылка на объект типа tree с данными о содержимом рабочей области
tree 9d548a63a91afe7da570cd7190888b7c59f1fc4f

# два родительских коммита — значит это мерж-коммит
parent a997a26aec530f536bc5949e4b316d685984dcd5
parent b6c26749463bf0c845637b127484ff6420b0148d

# автор, <почта автора>, UNIX timestamp, часовой пояс
author Nick Volynkin <email@server.tld> 1431889003 +0600
committer Nick Volynkin <email@server.tld> 1431889003 +0600

# сообщение
Merge branch 'newversion'

使用 SHA1 哈希函数“密封”提交的全部内容。此函数的值用作提交 ID。如果至少有什么变化，那么哈希函数的值将完全不同。

命令喜欢什么commit --amend和rebase

这些命令创建新的提交，但尽可能重用以前的内容。

例如，在帮助下git commit --amend我们可以更改内容、消息、最后一次提交的作者。提交者和日期将自动更改为从设置user.name <user.email>和当前时间获取的那些。由于内容变了，哈希也变了——这意味着你不能在上一次提交的地方保存这个内容——你需要创建一个新的。