不反对拥有大量资源的复杂代理。如今，SHA-1（在 git 中使用的哈希）被认为在密码学上不安全，可以防止碰撞攻击。使用已发布的完全碰撞方法估计在 EC2 计算时间上花费约 100,000 美元。这就是 SHA-1 SSL 证书被认为不安全的原因。

如果您忽略 SHA-1 冲突攻击的可能性，如果您将提交哈希交给某人（然后让他们访问存储库），他们可以使用该提交哈希来验证以下信息（以自定义格式一起哈希创建哈希）：

1. 当前树的完整 sha1 哈希（树本质上是提交的文件列表，文件名指向文件中数据的 sha-1 哈希）
2. 父提交的完整 sha1 哈希（在合并的情况下为多个）
3. 作者和提交者的姓名和电子邮件，
4. 提交的时间戳（根据提交者的本地计算机）
5. 提交消息

因此，如果您在特定时间通过电子邮件向某人发送特定的提交哈希43c5ab273a7c897dfd8cad9cef829b3a657f8491，他们稍后可以验证提交是指向特定树 ( 4c883b33dbb987e46c211f6dad52b91b208661b4)，其父提交为cef37643eb57177ac9e4e1f3d0178bc67b381c8e. 时间戳和作者/提交者信息也将包括在内，但这不应该被认为是准确的。例如，任何人都可以告诉他们本地的 git 实例，他们是他们想要的任何名称/电子邮件，并将其推送到他们控制的 bitbucket 存储库。

请注意，因此如果有人想验证您上个月是否以某种方式拥有存储库，您可以轻松返回并编辑历史记录并创建一个新提交（带有新哈希），以显示您当时以这种方式拥有存储库。但是，如果您当时给了他们一个哈希来提交存储库的状态，这是不可能的（不经历产生哈希冲突的麻烦）。

正如 jimbob 博士解释的那样，默认情况下 git 并不像您可能希望的那样安全。但是，对于这种情况有一个选项，即使用 GPG 对提交或标签进行签名。

如果您这样做，那么他们可能会更有力地保证您已创作了该作品；您现在主要依靠 GPG 和信任网络进行验证，而不是 git 本身。通常的 GPG 事情适用，例如他们需要信任您的密钥，您需要保护您的密钥安全等。

另请注意，如果您签署特定提交，则您正在验证导致该提交的整个提交历史的真实性。在您的情况下，这应该不是问题，因为您是存储库的唯一提交者，但在您工作时要记住这一点。

这可能仍然会给您带来证明时间的问题。该信息存储在提交中，但您可以控制它（最明显的是通过更改系统时钟）。因此，我们在本文结尾处得到了一个很好的保证，即您在您声称的某个时间提交了一些特定的文本。如果您想要保证您没有过时的数据，您将需要一个具有可信时钟的外部系统。