TLDR;
- 从 2005 年到 2018 年/Git 2.18：SHA-1 https://en.wikipedia.org/wiki/SHA-1（见下文）
-
2019年，将在某个时候切换 https://stackoverflow.com/a/47838703/6309 to SHA-256 https://en.wikipedia.org/wiki/SHA-2
您可以从以下位置检查:
（强调我的）
我们检查被认为是加密安全的校验和。没有人能够破解 SHA-1，但重点是，就 git 而言，SHA-1 甚至不是一个安全功能。这纯粹是一个一致性检查.
安全部分在其他地方。很多人认为由于 git 使用 SHA-1 并且 SHA-1 用于加密安全的东西，他们认为这是一个巨大的安全功能。它与安全性完全无关，它只是您可以获得的最佳哈希值。
拥有良好的哈希值有助于信任您的数据，它也恰好有一些其他好的功能，这意味着当我们对对象进行散列时，我们知道散列是很好分布的，并且我们不必担心某些分布问题。
从内部来看，这意味着从实现的角度来看，我们可以相信哈希值非常好，以至于我们可以使用哈希算法并且知道没有坏的情况。
因此，也有一些理由喜欢加密方面，但这实际上是关于信任您的数据的能力。
我向你保证，如果你把你的数据放在 git 中，你可以相信五年后，当它从你的硬盘转换到 DVD 到任何新技术并复制它时，五年后，您可以验证返回的数据与您输入的数据完全相同。这是您真正应该在源代码管理系统中寻找的东西.
2017 年 12 月更新为 Git 2.16（2018 年第一季度）：支持替代 SHA 的工作正在进行中：请参阅“为什么 Git 不使用更现代的 SHA？ https://stackoverflow.com/a/47838703/6309".
我在《git 将如何处理 blob 上的 SHA-1 冲突？ https://stackoverflow.com/a/9392525/6309“那个你could使用特定 SHA1 设计提交prefix（仍然是一项极其昂贵的努力）。
但重点仍然是埃里克·辛克 http://ericsink.com中提到“Git：加密哈希 http://ericsink.com/vcbe/html/cryptographic_hashes.html" (版本控制示例 (2011) 书 http://ericsink.com/vcbe/html/index.html:
DVCS 永远不会遇到具有相同摘要的两个不同数据片段，这一点相当重要。幸运的是，良好的加密哈希函数旨在使此类冲突极不可能发生。
比较难找到良好的非加密哈希 http://en.wikipedia.org/wiki/List_of_hash_functions碰撞率低，除非你考虑像“通过遗传编程寻找最先进的非加密哈希值 http://e-archivo.uc3m.es/bitstream/handle/10016/3987/finding_LNCS_2006_ps.pdf?sequence=1".
您还可以阅读“考虑使用非加密哈希算法来加速哈希 https://github.com/markfasheh/duperemove/issues/24”，其中提到例如“xxhash https://code.google.com/p/xxhash/”，一种极快的非加密哈希算法，工作速度接近 RAM 限制。
关于更改 Git 中的哈希值的讨论并不新鲜：
- either 对其进行优化（2009 年 8 月） http://www.mail-archive.com/bug-coreutils@gnu.org/msg17297.html，但你必须采取许可证问题：
（莱纳斯·托瓦尔兹）
其实什么都没有其余的mozilla 代码的一部分，但是嘿，我就是从它开始的。回想起来，我可能应该从 PPC asm 代码开始，它已经完成了理智的阻塞 - 但这是一种“20/20 事后诸葛亮”的事情。
另外，嘿，Mozilla 代码是一堆可怕的垃圾，这就是为什么我如此确信我可以改进一些东西。所以这是它的一种来源，即使它更多的是动机方面而不是任何实际的剩余代码;)
并且你需要小心如何衡量实际的优化增益 http://www.mail-archive.com/bug-coreutils@gnu.org/msg17305.html
（莱纳斯·托瓦尔兹）
我几乎可以向你保证，它改进了事情，只是因为它使 gcc 生成垃圾代码，然后隐藏了一些 P4 问题。
- or to 完全改变它（2010 年 1 月） http://lwn.net/Articles/370907/
（例如 SHA-3，但这也适用于任何其他哈希）：
（约翰·塔普塞尔 -johnflux https://github.com/johnflux)
将 git 从 SHA-1 升级到新算法的工程成本要高得多。我不知道如何才能做得好。
首先，我们可能需要部署一个 git 版本（在本次对话中我们称之为版本 2），它允许为新的哈希值提供一个插槽，即使它不读取或使用该空间 - 它只是使用另一个槽中的 SHA-1 哈希值。
这样一旦我们最终如果部署更新版本的 git，我们称之为版本 3，它除了 SHA-1 哈希值之外还生成 SHA-3 哈希值，使用 git 版本 2 的人们将能够继续进行互操作。
（尽管根据本次讨论，它们可能容易受到攻击，并且依赖仅 SHA-1 补丁的人也可能容易受到攻击。）
简而言之，切换到any哈希并不容易。
2017 年 2 月更新：是的，理论上可以计算冲突的 SHA1：粉碎.io https://shattered.io/
胃肠道如何受到影响？
GIT 强烈依赖 SHA-1 来对所有文件对象和提交进行识别和完整性检查。
基本上可以创建两个具有相同头提交哈希和不同内容的 GIT 存储库，例如一个良性源代码和一个后门源代码。
攻击者可能有选择地向目标用户提供任一存储库。这将要求攻击者计算自己的碰撞。
But:
此攻击需要超过 9,223,372,036,854,775,808 次 SHA1 计算。这相当于单 CPU 计算 6,500 年和单 GPU 计算 110 年的处理能力。
所以我们暂时不要惊慌。
更多信息请访问 ”Git 将如何处理 blob 上的 SHA-1 冲突？ https://stackoverflow.com/a/42450327/6309".
