Orien Daily
Git 的 .git/objects 里到底藏了什么？ git add → git commit → git push 这个流水线上，但如果你 ls .git/objects/ 看一眼，会发现一堆两级目录——前两位是 SHA-1 的前缀，剩下的在子目录里。这些就是 Git 的全部家当，所谓 content-addressable storage 的实体。.git/refs/heads/main 里的一行四十字符，指向某个 commit 而已。deflate 压缩。随便找个文件用 python -c "import zlib, sys; sys.stdout.buffer.write(zlib.decompress(open(sys.argv[1],'rb').read()))" .git/objects/xx/yyyy… 就能还原。你会看到开头是一行 header，格式是 类型 长度\0，比如 blob 158\0，然后是原始内容。这就是 Git 的寻址方式——对 header+content 算 SHA-1，前两位做目录名，后 38 位做文件名，内容 zlib 压缩后写入。碰撞概率在可预见的未来可以忽略，所以这个哈希就是对象的唯一身份证。git gc 会把它们打包成 .git/objects/pack/ 下的 .pack 和 .idx 文件。pack 内部对相似对象做 delta 压缩——只存与前一版本的差异，解压时链式还原。这也是为什么 git clone 大仓库比想象中快，网络传输的是 pack 格式而不是逐个对象。思考题：如果一个 blob 的内容刚好是另一个 blob 的前缀，pack 的 delta 压缩能利用这一点吗？Git 的 delta 选择策略是贪婪的还是全局最优的？ git cat-file -p 或 git ls-tree 查看对象时，想想这些命令背后不过是对一个 zlib 压缩文件的解压和解析。整个版本控制系统建立在三个朴素的数据结构和一个哈希函数之上，没有数据库，没有服务器——这个设计判断本身就是最大的工程智慧。
12:01 · May 19, 2026 · Tue
CS
