注意：您可以要求git rev-parse --short最短但唯一的SHA1。
请参阅“ git从常规哈希中获取短哈希 ”
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
如您在示例中所见，即使我指定的长度为4，SHA1的长度也为5。
对于大型存储库，自2010年以来7个还不够，因此请 Linus Torvalds本人提交dce9648（git 1.7.4.4，2010年10月）：
默认值7来自git开发的相当早的时候，当时7个十六进制数字很多（它涵盖了大约250+百万个哈希值）。
那时我以为65k修订版本很多（这是我们在BK中要达到的修订版本），每个修订版本通常大约有5-10个新对象，所以一百万个对象是一个很大的数目。
（BK = BitKeeper）
这些天来，内核甚至不是最大的Git项目，甚至内核约220K版本（多比BK树曾是大），我们正在接近200万级的对象。
那时，对于许多字符来说，七个十六进制数字仍然是唯一的，但是当我们谈论的是对象数量和散列大小之间仅两个数量级的差异时，截断的散列值将存在冲突。
它甚至不再接近于不现实-它一直在发生。
我们应该增加一个不切实际的默认缩写，并增加人们在git config文件中设置自己的默认每个项目的方法。
core.abbrev
设置长度对象名称的缩写。
如果未指定，则许多命令缩写为7个十六进制数字，这可能不足以使缩写对象名称在足够长的时间内保持唯一。
environment.c：
int minimum_abbrev = 4, default_abbrev = 7;
注意：如下面的marco.m所评论，在commit a71f09f中的同一Git 1.7.4.4中core.abbrevLength被重命名。core.abbrev
重命名core.abbrevlength为core.abbrev
--abbrev=$n毕竟它对应于命令行选项。
最近，Linus在提交中提交了e6c587c（适用于Git 2.11，2016年第4季度）：（
如Matthieu Moy的回答中所述）
在相当早的日子里，我们以某种方式决定将对象名称缩写为7个十六进制数字，但是随着项目的发展，越来越早地看到这样简短的对象名称并记录在日志消息中就不再唯一了。
当前，Linux内核项目需要11到12个十六进制数，而Git本身需要10个十六进制数来唯一地标识它们拥有的对象，而许多较小的项目可能仍然可以使用原始的7十六进制数。单一尺寸并不适合所有项目。
引入一种机制，在该机制下，我们会在第一个请求时估计存储库中的对象数量，以使用默认设置来缩写对象名称，并为存储库提出一个合理的默认值。基于预期，2^(2N)当使用对象名称缩短到前N位时，在存储库中会与对象发生冲突，请使用足够数量的十六进制数来覆盖存储库中的对象数量。
我们在缩写名称中添加的每个十六进制数字（4位）使我们在存储库中的对象数可以达到其四倍（2位）。
参见Linus Torvalds（）的commit e6c587c（2016年10月1日）。
参见Junio C Hamano（）提交的commit 7b5b772和commit 65acfea（2016年10月1日）。（通过合并JUNIOÇ滨野- -在提交bb188d0，2016年10月3日）torvalds
gitster
gitster
这个新属性（猜测SHA1缩写值的合理默认值）直接影响Git如何计算自己的版本号以进行发布。