我希望在我参与的vscode扩展中实现提交性能的缓存。一旦我缓存提交，我需要知道任何历史记录是否从rebase新提交等变化，所以我可以使缓存无效没有陈旧的信息。
是来自
的sha1
get rev-parse branchname
所有提交的好版本？
如何计算。 （它是所有提交sha1的{{1}}还是类似的东西？
答案 0 :(得分：2)
git rev-parse <branch-name>返回的sha1只是最终提交的sha1（<branch-name> ref当前指向的那个）。
那说，如果你有两个提交sha1值，并且它们匹配，你可以放心地假设所有内容和历史是相同的。
<强>更新
刚才意识到你特意问过它的计算方法;虽然我提到它是提交的sha1，但你可能知道或者可能不知道究竟代表什么，这与我声称你可以相信sha1匹配告诉你所有内容和历史都匹配......所以：
这就像git如何计算任何对象的sha1 - 通过在提交对象前加上一个小标头然后应用标准的sha1算法。并且因为sha1有160位，所以该值很可能唯一地标识提交对象的确切内容。但是提交对象中有什么？
好吧，它有一个提交消息和一些其他元数据，以及提交的根树和其每个父节点的哈希值。因此，如果两个提交哈希值匹配，则表示父哈希值匹配，并且您知道树哈希值匹配。
树包含文件名列表，每个文件名都引用blob（文件）或树（子目录），以及引用的blob或树的哈希。因此，对于要匹配的根树哈希，它必须包含相同的文件和目录，每个文件和目录都具有也匹配的哈希。您可能知道如果两个blob具有相同的哈希值，则它们被视为相同;并且递归地应用关于树的逻辑，您可以看到提交的整个内容必须匹配。
类似地，如果父哈希匹配，则由于相同的递归逻辑，每个父本身必须“相同”。 （即父级必须具有相同的元数据，内容和父级哈希，因此其父级（如果有）必须具有相同的元数据，内容和父级哈希等。）
相反，如果历史记录中的任何地方发生了变化 - 比如十年前提交的第三级子目录中的单个blob - 那么blob的哈希值会发生变化，因此包含的树哈希会发生变化，因此每个树都会更新对根树进行更改，因此包含提交哈希值会发生更改，因此其所有后代的哈希值都会更改。因此，如果你使用了提交哈希来注释发布文档，那么你可以遇到的问题，然后做一个过滤器分支操作......