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