使用Git我不明白如何使用SHA，你只能生成40个十六进制数字代码，然后可以映射到任何可能长达数百行的文件。
我想到它的方式，让我们说出字符串＆＃39; 1＆＃39; - ＆GT; 00 ... 01，字符串＆＃39; 2＆＃39; - ＆GT; 00..02，字符串＆＃39; a34ed..fc＆＃39; - ＆GT; a34ed..fc等所以哈希映射返回自己，然后它清楚地表明所有哈希码都很快用完了，任何41个字符长的字符串将重用其中一个代码。
我也知道SHA并不知道它不会保证它总是独一无二的，但我也不知道它是如何接近有用的。
答案 0 :(得分：4)
SHA-1哈希值为160位。这给你2 160 ，或者完全
1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976
可能的哈希。
假设哈希值或多或少是不可预测的，那么意外具有相同哈希值的两个文件的几率是无穷小的，以至于它不值得担心它。
引自Scott Chacon的书"Pro Git"：
然而，你应该知道这是多么荒谬 情景是。 SHA-1摘要是20字节或160位。的数量 随机散列的对象需要确保单个概率为50％ 碰撞大约是2 80 。
...
这是一个例子，可以让您了解获得a所需的内容 SHA-1碰撞。如果地球上所有65亿人都在编程， 每一秒，每一个都产生相同的代码 整个Linux内核历史（100万Git对象）和推送 它进入一个巨大的Git存储库，需要5年时间 存储库包含足够的对象，具有50％的概率 单个SHA-1对象冲突。每个人都有更高的可能性 你的编程团队成员将被狼攻击并杀死 在当晚的无关事件中。
确实必须有两个具有相同SHA-1哈希的21字节文件（因为有2个 168 这样的文件而且只有2个 160 可能的SHA-1哈希）。 从未发现过这样的文件。
更新：截至2017年2月，已生成两个具有相同SHA-1校验和的不同PDF文件，其使用的技术速度是蛮力攻击速度的100,000倍以上。详情请见https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
Linux Torvalds（Git的作者）在此发布了一条（初步）回复：http://marc.info/?l=git&m=148787047422954
答案 1 :(得分：1)
事实上，我称之为“安全边际”决定了你可以存储的对象数量。
广泛引用的“约2 80 ”数字是您有大约50％的机会发生哈希冲突的点。为了保持机会低于10 <1> 18 中的1个，存储库中不同对象的数量不应超过约1.7千万亿（1.71x10 15 ）。
（我为一本我正在研究的书做了一些数学计算;我没有让一位真正的数学家检查过它，但是当我针对其他散列大小运行相同类型的数字时，我的输出同意{{3对于任何值得的东西。:-)）
编辑添加：这是近似公式。设 r 为哈希函数的基数（因此 r 为SHA-1的2 160 ）和 U 是所需的唯一概率（因此 U 为0.5，通常为“50％安全概率，50％碰撞几率”统计。最大哈希输入数为：
（1 + sqrt（1 + 8 r ln（1 / U ））/ 2
1 / .5的自然对数约为0.693，因此我们有大约sqrt（4
要查看（球场）我如何得到我的数字 - 在10 15 对象附近 - 让 U = 1 - 10 -18 。这个数字的自然对数基本上是最初的10 -18 ，这意味着我们将 60 的大部分从 r 范围内击出，留下约2 100 。其平方根约为2 50 ，约为10 15 。
答案 2 :(得分：0)
错误是SHA代码不用于生成任何文件的内容，内容由Git分别存储。 SHA代码仅用作提交的密钥。提交的原因不能仅仅是从1开始编号并且增加的原因是因为使用Git，不同的人可以在同一个项目的不同分支上工作而不知道彼此。当这些合并在一起时，我们仍然需要提交具有唯一键。使密钥绝对唯一的最佳方法是使用类似SHA的东西创建一个独特的代码，而其他人已经解释了获得相同密钥几乎为零的概率。