Git如何识别历史版本？关于历史提交对象检索机制的疑问

其实Git完全不需要反向解密SHA1——它是靠提交链和对象间的引用关系来定位旧文件的，核心逻辑跟哈希解密半毛钱关系都没有。

咱们拆开说：

• 首先，Git里的每个提交（commit）都是一个完整的快照，它本身是个对象，里面存着对应版本的树对象（tree）哈希。而树对象就像目录结构，里面记录了当前版本下所有文件/子目录对应的blob对象哈希（blob就是存文件内容的对象）。

• 当你修改文件并提交新版本时，Git会生成新的blob、新的tree、新的commit，但旧版本的commit、tree、blob全都会保留在objects目录里——除非你手动做了垃圾回收（git gc）清理掉未被引用的对象。

• 当你要找回旧文件时，比如执行git checkout <旧commitID> -- 文件名，Git的流程是这样的：

  1. 根据你提供的旧commit哈希，找到对应的commit对象；
  2. 从commit对象里取出它对应的tree哈希，找到这个tree对象；
  3. 在tree对象里找到目标文件对应的blob哈希；
  4. 直接去objects目录里找以这个blob哈希命名的文件（比如哈希是a12345...，文件路径就是objects/a1/2345...），解压后就是旧文件的内容。

简单说，SHA1在这里只是个唯一的对象ID，Git是顺着「commit → tree → blob」的引用链找到对应的哈希，再用哈希直接读取已经存在的对象文件——全程不需要反向推导哈希对应的内容，因为内容早就存在仓库里了。

举个实际的例子：
你第一次提交文件readme.txt，Git生成：

• blob对象（存readme的内容，哈希为abc123）
• tree对象（记录readme.txt对应abc123，哈希为def456）
• commit对象（指向treedef456，哈希为ghi789）

修改readme后第二次提交，Git生成：

• 新blob对象（内容更新，哈希jkl012）
• 新tree对象（记录readme.txt对应jkl012，哈希mno345）
• 新commit对象（指向treemno345，哈希pqr678）

这时候旧的abc123、def456、ghi789都还在objects目录里。当你要找第一次提交的readme，Git就从ghi789找到def456，再找到abc123，直接读取这个blob文件的内容就行。

内容的提问来源于stack exchange，提问作者Erdasiuuu