Git（Hub）如何处理短SHA可能的冲突？
Git和GitHub都显示SHA的短版本 – 只是前7个字符，而不是全部40个字符 – 而且Git和GitHub都支持把这些短SHAs作为参数。
例如git show 962a9e8
例如https://github.com/joyent/node/commit/962a9e8
考虑到可能性空间现在降低了几个数量级，“仅仅2.68亿” ，Git和GitHub如何在这里防止碰撞？ 他们如何处理他们？
这些简短的forms只是为了简化视觉识别，让您的生活更轻松 。 Git不会真的截断任何东西，内部的一切都将被完整的处理。 尽pipe如此，您可以在方便的时候使用部分SHA-1：
只要你的部分SHA-1至less有4个字符长和明确 – 即当前版本库中只有一个对象开头，那么Git足够聪明，可以知道你提供了什么types的提交。那部分SHA-1。
我有一个存储库，提交的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年所做的）
这里有两个注释：
-
如果你在显示提交的GitHub页面的任何地方键入y ，你将看到提交的全部40个字节。
这说明浮雕的重点：GitHub不截断任何东西。 -
无论如何，2010年以来的7位是不够的。
见Linus Torwalds本人的commit dce9648 （2010年10月，git 1.7.4.4）：
7的默认值来自git开发的早期，当七个hex数字是很多（它涵盖了大约250多万散列值）。 那时候我以为65K的修改是很多的（这是我们打算在BK里面打的），每个版本都会有5-10个左右的新东西，所以一百万个对象是一个很大的数字。
（BK = BitKeeper）
现在，内核甚至不是最大的git项目，甚至内核也有大约22万个版本（比BK树大得多），我们正在接近200万个对象。 在那个时候，七个hex数对于它们中的许多来说仍然是唯一的，但是当我们谈论对象的数量和散列大小之间仅仅两个数量级的差异时，在截断的散列值中将会有冲突。 它不再是不切实际的 – 它总是发生。
我们应该增加一个不切实际的小默认缩写， 并且为人们在gitconfiguration文件中设置他们自己的默认每个项目添加一个方法。
