这是一个老问题，但有一件事需要澄清：
这个问题和下面的答案讨论的是文件的Git哈希，它与问题中所问的*"此文件的SHA1"* 不完全相同。
简而言之：
如果你想得到index中文件的Git哈希值--参见CB Bailey的答案：

git ls-files -s $file

如果你想得到文件系统中任何文件的Git哈希值--请看cnu的答案：

git hash-object $file

如果你想获取文件系统中任何文件的Git哈希值，而你没有安装Git：

(echo -ne "blob `wc -c < $file`\0"; cat $file) | sha1sum

(The上面显示了Git散列实际上是如何计算的-它不是文件的sha1和，而是字符串**"blob SIZE\0CONTENT"的sha1和，其中"blob"字面上是字符串"blob"（后跟空格），SIZE是文件大小（以字节为单位）（ASCII十进制），"\0"为空字符，CONTENT为实际文件内容）。
如果您只想获得"此文件的SHA1"**，如问题中所问：

sha1sum < $file

如果没有sha1sum，可以使用shasum -a1或openssl dgst -sha1（输出格式略有不同）。

您需要git ls-files的-s选项，这将为您提供索引中文件的模式和sha1散列。

git ls-files -s myfile.java

请注意，您不需要git hash-object，因为这将为您提供当前工作树中文件的sha1 id，而不是您添加到索引中的文件的sha1 id。一旦您在git add之后对工作树副本进行更改，这些将有所不同。

$ git hash-object myfile.java
802992c4220de19a90767f3000a79a31b98d0df7

警告：如果你需要在 * 太多 * 文件上获取SHA1，你会得到一个错误，因为Git 2.40（Q1 2023）修复了一个漏洞：
参见Jeff King ( peff )（2023年1月18日）。
（由Junio C Hamano -- gitster --合并至commit 630ae5e，2023年1月27日）

hash-object：使用--字面意思修复描述符泄漏

签署人：杰夫·金
在hash_object()中，我们为每个要散列的文件打开一个描述符（无论是从命令行还是--stdin-paths获得文件名），但从不关闭它。
对于传统的代码路径，它将结果提供给index_fd()，这是可以的;它为我们关闭描述符。
但是5ba9a93（"hash-object：add（man）--literally选项"，2014 - 09 - 11，Git v2.2.0-rc0--merge）添加了第二个代码路径，它不关闭描述符。
在这方面，我们需要自己这样做。
您可以在git.git的克隆中看到这样的问题：

$ git ls-files -s | grep ^100644 | cut -f2 |
  git hash-object --stdin-paths --literally >/dev/null
fatal: could not open 'builtin/var.c' for reading: Too many open files

在此修补程序之后，它将成功完成。
在Git 2.39中，我的一个仓库显示了这个错误：

vonc@vclp MINGW64 ~/git/seec2 (main)
$ git ls-files -s | grep ^100644 | cut -f2 | git ls-files -s | grep ^100644 | cut -f2 | \
git hash-object --stdin-paths --literally
fatal: could not open 'data/commits/7f/a3338870d66dd3946c5c3a0bd09dadb798893d' for reading: Too many open files