在Git中，长短哈希有什么区别？

Question

这是长Git哈希：

提交c26cf8af130955c5c67cfea96f9532680b963628

合并：8654907 37c2a4f

作者：尼古拉斯

日期：4月26日星期三13:28:22 2017 -0400

这是一个简短的：

Answer 1

为了详细说明为什么短哈希是有用的，以及为什么你经常不需要长哈希，它与Git如何存储事物有关。

c26cf8af130955c5c67cfea96f9532680b963628将被存储在两个地方之一。它可以在文件.git/objects/c2/6cf8af130955c5c67cfea96f9532680b963628中。请注意，前两个字符c2构成一个目录，其余的是文件名。由于许多文件系统在一个目录中的文件太多时性能不佳，这可以防止任何一个目录中包含太多文件并保持这个小目录数据库的效率。

只有短哈希，c26cf8a，git可以做相当于.git/objects/c2/6cf8a*，这可能是一个单独的文件。由于对象被细分为子目录，因此没有太多文件名需要查看以检查是否存在多个匹配项。

单独的c26cf8a包含足够的可能性，16 ^ 7或2 ^ 28或268,435,456，这是不太可能另一个提交将共享该前缀。

基本上，Git使用文件系统本身作为一个简单的键/值存储，它可以查找部分键而无需扫描整个键列表。

---

这是存储对象的一种方法。 Git越来越多地将其对象存储在packfiles中。这是一种非常有效的方式来存储文件之间的变化。有时，您的Git存储库将检查.git/objects中的内容并仅存储.git/objects/pack/pack-<checksum>中的差异。

这是一种二进制格式，我不打算在这里进入它，我自己也不了解它。 :)

Answer 2

短哈希只是完整哈希的前7个字符。

在屏幕截图中带圆圈的提交正下方，您可以看到标记为c26cf8a的提交。这应该是你正在寻找的提交c26cf8af130955c5c67cfea96f9532680b963628。

Answer 3

短哈希显示哈希的前七个字符。 c26cf8af130955c5c67cfea96f9532680b963628的短哈希是第二行中的c26cf8a。见the documentation：

只要你的部分SHA-1长度至少为4个字符并且明确无误，Git就足够聪明，可以弄清楚如果提供前几个字符，你打算输入什么。

Answer 4

短哈希只是原始（长）哈希的较短版本。原始Git散列长度为40个字节，而短消息长度仅为8个字节。但是，管理它（在使用打字或显示方面）变得很困难，这就是使用短版本的原因。

这种方法几乎用于所有哈希用于完整性（包分发），版本控制（Git和SVN）或分层体系结构（Docker）的项目中。