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

Question

这是长Git哈希:

提交c26cf8af130955c5c67cfea96f9532680b963628

合并:8654907 37c2a4f

作者:尼古拉斯

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

这是一个简短的:

Answer 1

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

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

只有短哈希,c26cf8agit可以做相当于,.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。请参阅文档：

只要您提供的前几个字符，只要您的部分SHA-1至少长四个字符且毫不含糊，Git就足够聪明地弄清楚您要键入的内容。

Answer 4

短哈希只是原始（长）哈希的较短版本。原始的 Git hash 长 40 个字节，而 Short 只有 8 个字节长。然而，管理它变得很困难（在使用打字或显示方面），这就是使用简短版本的原因。

这种方法几乎用于所有项目，其中哈希要么用于完整性（包分发）、版本控制（Git 和 SVN），要么用于分层架构（Docker）。