git - 10个十六进制数字git hash缩写就够了吗？

需要多少个可能的哈希值才能避免N项目之间的冲突？如果你回想生日悖论，答案就比这个小得多N。

让我们把问题反过来：对于N=16^10可能的哈希值，它对应于 10 个十六进制数字的缩写 git 修订代码，有多少修订，修订哈希重合的概率上升到 50%？直接计算表明，如果您有 1234603 个修订版本，其中两个具有相同 10 位哈希的概率为 50%。

现在，在大型活动存储库中，一百万左右的修订并非闻所未闻。这里有人在你的工作中经历过 git hash 冲突吗？从理论上讲，这应该发生了。

标签： githashname-clash

随着对象数量的增加，Git 会自动缩放缩写哈希的长度，因此这通常不是问题。此外，如果一个缩写的散列在正常长度下是不明确的，Git 会自动生成一个更长的、明确的值。一些命令允许您使用一个选项来控制缩写的长度，--abbrev如果您想要一个特定的值，该core.abbrev选项可以覆盖默认值。

但是，这些名称必须仅在创建时是唯一的，因此如果您正在生产需要使用修订版的工具，它们应该始终对完整的对象 ID 进行操作。另请注意，正在切换到使用 SHA-256 的工作正在进行中，因此在编写工具时，您不应假设特定完整对象 ID 的长度。