这是长 Git 散列:
提交 c26cf8af130955c5c67cfea96f9532680b963628
merge :8654907 37c2a4f
作者:尼古 pull 斯
日期:2017 年 4 月 26 日星期三 13:28:22 -0400
这是简短的:
最佳答案
要详细说明为什么短散列有用，以及为什么您通常不需要长散列，这与 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> 中。
那是二进制格式，这里就不深究了，反正我自己也不懂。 :)
关于git - 在 Git 中，长散列和短散列有什么区别？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43665836/