存储在树对象中的 SHA1 哈希值（git ls-tree 返回的）与文件内容的 SHA1 哈希值（sha1sum 返回的）不匹配
$ git cat-file blob 4716ca912495c805b94a88ef6dc3fb4aff46bf3c | sha1sum
de20247992af0f949ae8df4fa9a37e4a03d7063e -
git 如何计算文件哈希？它会在计算哈希之前压缩内容吗？
【问题讨论】：
标签： git hash sha1 checksum git-hash
Git 以“blob”作为对象的前缀，后跟长度（作为 人类可读的整数），后跟一个 NUL 字符
$ echo -e 'blob 14\0Hello, World!' | shasum
8ab686eafeb1f44702738c8b0f24f2567c36da6d
来源：http://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html
【讨论】：
echo 'Hello, World!' | git hash-object --stdin 的输出进行比较。或者，您可以指定 --no-filters 以确保不发生 crlf 转换，或指定 --path=somethi.ng 以让 git 使用通过 gitattributes 指定的过滤器（也是 @user420667）。和 -w 实际将 blob 提交给 .git/objects（如果您 在 在 git repo 中）。
echo -e 'blob 16\0Hello, \r\nWorld!' | shasum == echo -e 'Hello, \r\nWorld!' | git hash-object --stdin --no-filters 也将与\n 和 15 等价。
echo 在输出中附加一个换行符，该换行符也传递给 git。这就是为什么它有 14 个字符。要使用不带换行符的 echo，请编写 echo -n 'Hello, World!'
我只是扩展@Leif Gruenwoldt 的答案并详细说明@Leif Gruenwoldt 提供的reference 中的内容
自己动手..
- 步骤 1. 在您的存储库中创建一个空文本文档（名称无关紧要）
- 第 2 步。暂存并提交文档
- 步骤 3. 通过执行
git ls-tree HEAD识别 blob 的哈希值- 步骤 4. 找到 blob 的哈希为
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391- 第 5 步。摆脱惊喜，阅读下文
GIT 如何计算其提交哈希
Commit Hash (SHA1) = SHA1("blob " + <size_of_file> + "\0" + <contents_of_file>)
文本blob⎵ 是一个常量前缀，\0 也是常量并且是NULL 字符。 <size_of_file> 和 <contents_of_file> 因文件而异。
见：What is the file format of a git commit object?
这就是所有人！
等一下！，您注意到<filename> 不是用于哈希计算的参数吗？如果两个文件的内容相同，而与它们的创建日期和时间以及它们的名称无关，则它们可能具有相同的哈希值。这是 Git 比其他版本控制系统更好地处理移动和重命名的原因之一。
自己动手（分机）
- 步骤 6. 在同一目录中创建另一个具有不同
filename的空文件- 第 7 步。比较两个文件的哈希值。
注意：
该链接没有提到tree 对象是如何被散列的。我不确定算法和参数，但是根据我的观察，它可能会根据它包含的所有 blobs 和 trees （可能是它们的哈希值）计算一个哈希值
【讨论】：
SHA1("blob" + <size_of_file> - blob 和大小之间是否有额外的空格字符？大小是十进制吗？它是零前缀的吗？
git hash-object
这是验证您的测试方法的快速方法：
s='abc'
printf "$s" | git hash-object --stdin
printf "blob $(printf "$s" | wc -c)\0$s" | sha1sum
输出：
f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f
f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f -
sha1sum 在 GNU Coreutils 中的位置。
然后归结为了解每种对象类型的格式。我们已经介绍了琐碎的blob，下面是其他的：
【讨论】：
$(printf "\0$s" | wc -c)。注意添加的空字符。也就是说，如果字符串是 'abc' 并且前面添加了空字符，则长度将产生 4，而不是 3。那么 sha1sum 的结果与 git hash-object 匹配。
基于Leif Gruenwoldt 的答案，这里是git hash-object 的shell 函数替代：
git-hash-object () { # substitute when the `git` command is not available
local type=blob
[ "$1" = "-t" ] && shift && type=$1 && shift
# depending on eol/autocrlf settings, you may want to substitute CRLFs by LFs
# by using `perl -pe 's/\r$//g'` instead of `cat` in the next 2 commands
local size=$(cat $1 | wc -c | sed 's/ .*$//')
( echo -en "$type $size\0"; cat "$1" ) | sha1sum | sed 's/ .*$//'
}
测试：
$ echo 'Hello, World!' > test.txt
$ git hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d
$ git-hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d
【讨论】：
我在 Python 3 中的一些单元测试中需要它，所以我想把它留在这里。
def git_blob_hash(data):
if isinstance(data, str):
data = data.encode()
data = b'blob ' + str(len(data)).encode() + b'\0' + data
h = hashlib.sha1()
h.update(data)
return h.hexdigest()
我在所有地方都坚持使用\n 行结尾，但在某些情况下，Git 在计算此哈希之前也可能是changing your line endings，因此您可能还需要一个.replace('\r\n', '\n')。
【讨论】：