Git（Hub）如何处理来自短SHA的可能冲突？

Git和GitHub都显示SHA的短版本——只有前7个字符而不是全部40个字符——并且Git和GitHub都支持将这些短SHA作为参数

例如，

git show 962a9e8

例如

---

考虑到可能性空间现在比“just”低了几个数量级，Git和GitHub在这里如何防止冲突？它们是如何处理的？

我有一个存储库，它有一个id为

000182eacf99cde27d5916aa415921924b82972c

的提交

git show 00018

显示修订，但

git show 0001

印刷品

error: short SHA1 0001 is ambiguous.
error: short SHA1 0001 is ambiguous.
fatal: ambiguous argument '0001': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

---

（如果你好奇的话，它是git本身的git存储库的克隆；这个提交是Linus Torvalds在2005年做出的。）

这些简短的表单只是为了简化视觉识别，让你的生活更美好。Git并没有真正截断任何内容，在内部，所有内容都将使用完整值进行处理。您可以在方便的时候使用部分SHA-1，但是：

Git非常聪明，只要您的部分SHA-1至少有四个字符长且不含糊，就可以知道您要键入什么commit，也就是说，当前存储库中只有一个对象以该部分SHA-1开头

这里有两个注释：

• 如果在显示提交的GitHub页面的任意位置键入y，您将看到所述提交的完整40字节。
  这说明了他的观点：GitHub不会截断任何东西

• 自2010年以来，7个十六进制数字（28位）是不够的。
  见Linus Torwalds本人（2010年10月，git 1.7.4.4）：

默认值7来自于git开发的早期，当时七个十六进制数字非常多（它覆盖了大约2.5亿多个散列值）。当时我认为65k版本很多（这是我们在BK中即将遇到的版本），每个版本大约有5-10个版本 新的物体，所以一百万个物体是一个很大的数字

（BK=比特保持器）

现在，内核甚至不是最大的git项目，甚至内核也有大约220k的修订版（比BK树大得多），我们正在接近200万个对象。在这一点上，七个十六进制数字对于很多数字来说仍然是唯一的，但是当我们 如果只讨论对象数量和散列大小之间的两个数量级差异，则截断的散列值会发生冲突。这已经不再接近于不切实际——它一直都在发生

我们应该增加默认的abbrev，这是不切实际的小，并添加一种方式，让人们在git配置文件中为每个项目设置自己的默认值

---

这在GitHub级别上不会引起关注，因为sha1对于每个单独的项目都是唯一的。两个7字符的短sha1仍然完全有可能在单个项目中发生冲突。有人知道是否有可能通过GitHub的API通过短SHA获取提交。。。例如，返回我需要的提交，但不感谢！该链接进一步阐述：“Git可以为您的SHA-1值找出一个简短、唯一的缩写。如果您将

--abbrev commit

传递给Git log命令，则输出将使用较短的值，但保持其唯一性；它默认使用七个字符，但如果需要，会使它们变长，以保持SHA-1的明确性。”另一句有用的话：“一般来说，8到10个字符就足以在一个项目中保持唯一性。最大的Git项目之一Linux内核开始需要40个字符中的12个字符才能保持唯一性。”您的链接已断开…：（如果您需要知道哪些对象与您不明确的id相匹配（

0001

），你可以做

git rev list--all--objects | grep^0001

。在你有了可能的完整sha1列表之后，你可以为每个sha1做

git show

。展示了如何只用git命令消除歧义。我很好奇，最大的git项目是什么？或者至少，绝对大规模的git回购的一些最好的例子是什么？@GeorgeMillo如中所述，您有两种大型回购（大型历史或大型二进制文件）大型git回购的一个例子是Facebook回购：（从那时起他们切换到自己版本的Mercurial）您的意思是7个十六进制数字（28位），不是7位。@ThomasJacob谢谢。我已经相应地编辑了答案。@ThomasJacob注意：SHA1并不总是Git中使用的默认哈希算法。这是不断发展的：