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

Question

这是长Git哈希：

提交c26cf8af130955c5c67cfea96f9532680b963628

合并：8654907 37c2a4f

作者：nicolas

日期：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长度至少为四个字符并且明确无误，Git就足够聪明地弄清楚你打算输入什么。

Answer 4

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

这种方法几乎用于所有项目，其中哈希是完整性（包分发），版本化（Git和SVN）或分层< / em> architecture（Docker）。