Git对象模型深度解析：blob、tree、commit与内容寻址原理

我自己啃 Git 文档那会儿，最崩溃的不是命令记不住，而是总觉得 Git 像黑盒一样：commit 之后数据到底存哪了？分支切换为什么这么快？为什么有时候删掉的分支还能找回来？直到我认真读完了入门章节里关于 Git 对象的部分，才一下子把整条链路串起来。这篇笔记就是围绕“Git 对象”这个话题展开的，原书是英文版，我一边翻译一边做了大量实操验证。如果你也处于“会用几个命令但心里没底”的阶段，这篇应该能帮你把地基补上。

这篇笔记不会只贴命令，我会把对象模型的原理、对象在 .git 目录里的真实存储形态、以及“对象——树——提交——引用”这条完整链路全部拆开讲一遍，最后附上我翻译和实操时踩过的坑。看完之后，你再遇到 git cat-file、git ls-tree、git fsck 这类“冷门命令”，就不会觉得它们只在教科书里出现了。

1. 为什么 Git 对象值得单独拿出来学

1.1 从一次误操作说起

先讲个我自己的经历。有次我在分支上改了一堆文件，不小心执行了 git reset --hard，之后发现改动全没了，当时第一反应是“完蛋了”。后来想到 Git 有个机制是对象不会立刻被物理删除，就抱着试一试的心态用 git fsck --lost-found 扫了一遍，居然真的找回了一个悬空提交，里面就是我丢失的那次改动。

这件事让我意识到：Git 的日常操作，本质上都是在“对象”之间辗转腾挪。分支、提交记录、文件内容、目录结构，这些你天天摸的东西，底层全是 Git 对象。搞清楚对象的存储和引用方式，不光能帮你理解命令背后的逻辑，还能在极端情况下把数据救回来。很多初学者觉得“对象模型”是进阶内容，其实它恰恰是最基础的地基，只是大多数教程把它放到了后面或者干脆不讲。

1.2 对象模型和日常命令的关系

你可能每天都在用 git add、git commit、git branch，但你有没有想过，这些命令到底在操作什么？一句话概括：git add 是把文件内容封装成数据对象并写入对象库，git commit 是创建一个提交对象，而分支只是一个指向提交对象的“指针文件”。

这就像你往仓库里搬货：货本身是数据对象，货架上的标签是树对象，快递单是提交对象，而“6号货架”这个指引是分支。没有这套对象模型，Git 的增量存储、快速分支、灵活回滚全都无从谈起。所以，与其一个个死记硬背命令，不如先把对象模型吃透，你会发现很多命令其实是“同一件事的不同说法”。

2. Git 对象的种类与存储机制

2.1 四种核心对象：blob、tree、commit、tag

Git 对象库里主要有四种对象，我一边翻译一边做了个对照表，方便你理解英文术语和中文译法之间的对应关系：

最开始我对 blob 不太理解，因为它只存内容、不存文件名，听起来很反直觉。但仔细想就明白了：同一个文件改个名字，内容没变，那 blob 对象就可以复用，Git 就不需要重新存储一遍内容。这种设计非常节省空间，也是 Git 高效的原因之一。

2.2 内容寻址与 SHA-1 哈希

Git 对象不是用“文件名”来索引的，而是用内容算出来的哈希值来索引。这种机制在英文里叫 content-addressable storage，中文一般译为“内容寻址存储”。Git 默认使用 SHA-1 哈希算法，对对象内容做一次哈希计算，得到一串 40 位的十六进制字符串，这个字符串就是对象的“身份证号”。

你可以这样理解：每个对象的内容只要有一点变化，哈希值就会完全不一样。所以同一个内容的文件，无论你放在哪个目录、叫什么名字，计算出的对象哈希都一样；反过来，内容不同，哈希就一定不同。Git 就靠这个哈希值直接在对象库里定位数据，不需要遍历查找，速度特别快。

我在翻译“content-addressable”这个词时纠结了很久，直译是“内容可寻址”，听起来很学术。后来我在笔记里加了句解释：“就是拿着内容本身当门牌号，内容就是地址，地址就是内容。”这样一看就懂了。

2.3 对象在 .git/objects 里的真实存储形态

当你执行 git commit 之后，对象会被写到 .git/objects 目录下。但 Git 不会直接以纯文本形式存储，而是先用 zlib 压缩，再按哈希值的前两位建子目录、剩余 38 位做文件名。比如一个对象的哈希是 5bdcf2...，那它的物理路径就是 .git/objects/5b/dcf2...。

这种“两级目录”的设计有两个好处：一是避免单个目录下文件太多，影响文件系统性能；二是通过哈希前缀就能快速定位对象文件。我在自己的测试仓库里执行过：

bash复制find .git/objects -type f

看到的输出是一堆由两个字符组成的目录，下面躺着 38 位文件名的文件。刚开始觉得乱，理解了规则之后反而觉得很清爽，因为这意味着任何对象都可以通过哈希值直接找到，不需要额外的索引文件。

3. 用命令亲手拆解 Git 对象

3.1 初始化仓库并观察对象库

只看概念容易飘，动手验证才踏实。我建议你跟我一起做一遍。先建一个全新的测试仓库：

bash复制mkdir git-objects-demo
cd git-objects-demo
git init

执行完之后，看一下对象库：

bash复制find .git/objects -type f

你会发现，初始状态下 objects 目录里只有 info 和 pack 两个空子目录，没有任何对象。这很正常，因为仓库刚建好，还没有任何内容被写入。接下来我们一步步往里塞对象。

3.2 生成第一个 blob 对象

先来创建一个最简单的 blob 对象。这里用 git hash-object，它可以把一段内容计算成哈希，如果加上 -w 参数，还会把对象写入对象库：

bash复制echo "hello git" | git hash-object -w --stdin

执行后终端会打印一串哈希，比如：

text复制5bdcf2f1a1f0d5d4f1a1f0d5d4f1a1f0d5d4f1a1

注意，我这里只是示例，实际哈希值会不一样。这时再执行：

bash复制find .git/objects -type f

就能看到一个真实的对象文件躺在对象库里了。想看这个对象的类型、大小和内容，用 git cat-file：

bash复制git cat-file -t 5bdcf2f1
git cat-file -s 5bdcf2f1
git cat-file -p 5bdcf2f1

-t 显示类型（这里应该是 blob），-s 显示大小，-p 以更友好的方式打印内容。看到输出的那一刻，你会对“blob 只存内容、不存文件名”有切身体会：这条命令根本不需要文件名，因为对象本身就是内容。

3.3 用 git write-tree 和 git commit-tree 构建 tree 和 commit

blob 只是最底层的数据对象，真正把文件组织成目录结构的是 tree 对象。我们模拟一个最简单的场景：在工作区创建两个文件，然后 git add，把内容写入对象库并生成索引：

bash复制echo "version 1" > readme.txt
echo "hello git" > hello.txt
git add readme.txt hello.txt

执行 git add 之后，这两个文件的内容已经被转换成了 blob 对象。接着用 git write-tree 把当前暂存区的内容打包成一个 tree 对象：

bash复制git write-tree

这会输出一个 tree 对象的哈希。然后用 git cat-file -p 查看这个 tree 的内容：

bash复制git cat-file -p <tree-hash>

输出大概是这样的：

text复制100644 blob 5bdcf2f1...	hello.txt
100644 blob 8a6f2f3c...	readme.txt

每一行代表 tree 里的一个条目，包括文件模式、对象类型、对象哈希和文件名。这个 tree 对象就是“当前目录的快照”。

再下一步，创建 commit 对象。git commit-tree 可以把一棵树打包成一个提交：

bash复制git commit-tree <tree-hash> -m "first commit"

执行后会输出一个 commit 对象哈希。用 git cat-file -p 查看：

bash复制git cat-file -p <commit-hash>

你会看到类似这样的结构：

text复制tree 9f2a3b4c...
author Your Name <you@example.com> 1712345678 +0800
committer Your Name <you@example.com> 1712345678 +0800

first commit

commit 对象里最重要的信息就是它指向哪个 tree、作者是谁、提交消息是什么。如果是后续提交，还会有 parent 行，指向父提交。

3.4 用 git ls-tree 和 git cat-file 查看对象之间的关系

tree 对象为什么重要？因为它保存了目录结构。如果目录里有子目录，tree 里就会多一个指向子 tree 的条目。可以用 git ls-tree 查看 tree 的条目：

bash复制git ls-tree <tree-hash>

默认会显示人类可读的格式，包括文件模式、对象类型、哈希和文件名。想只看树的结构，可以加 -r 递归列出所有子条目：

bash复制git ls-tree -r <tree-hash>

我在做笔记时习惯把自己想象成一个“对象侦探”：拿到一个 commit 哈希，就用 cat-file -p 看它指向哪棵树，再用 ls-tree 看这棵树里有哪几个文件，再顺着文件名找到 blob 对象，最后用 cat-file -p 看文件内容。这一整套操作下来，提交、目录、文件内容三层结构就全串起来了。

3.5 工作区、暂存区与对象库的关系

你可能会问：那 git add 到底干了什么？答案是把工作区的文件内容变成 blob 对象，同时把“文件名 → 对象哈希”的对应关系写到暂存区。暂存区在 .git/index 文件里，它本质上是一个扁平的清单，记录着当前暂存状态下每个文件对应的对象。

我当初一度把“暂存区”理解成“对象库的一部分”，这是错的。对象库是真正存内容的地方，暂存区只是“目录清单”。当 git commit 执行时，Git 根据暂存区的内容生成一个 tree 对象，再创建 commit 对象指向这棵树。所以你可以理解为：add 在准备内容，commit 在拍板打包。

4. 引用、HEAD 与对象可达性

4.1 分支本质上是一个“指针文件”

如果你打开 .git/refs/heads 目录，会看到每个分支对应一个文件，文件内容就是 40 位的提交哈希。也就是说，分支不是一个神奇的实体，它只是一个指向 commit 对象的引用。Git 在英文里管这叫 ref，中文一般译为“引用”。

我之前有个误区，以为分支是“一串提交组成的链”。实际上链是推出来的，分支本身只是链上的最后一个节点。当你提交新 commit 时，Git 做的事情很简单：创建一个新的 commit 对象，然后把当前分支的引用文件指向这个新 commit。至于之前的 commit，它们会通过 parent 字段逐级串联起来，形成历史。

4.2 HEAD、分支切换与 git log 的遍历逻辑

HEAD 是一个特殊的符号引用，通常指向当前分支，而不是直接指向提交。你可以看 .git/HEAD 文件：

bash复制cat .git/HEAD

输出一般是：

text复制ref: refs/heads/master

这意味着“当前所在分支是 master”。当你执行 git checkout 或 git switch 切换分支时，Git 做的事情之一就是把 HEAD 指向另一个分支引用，然后更新工作区的文件内容。由于对象模型是内容寻址的，切换分支只需要根据新分支指向的 commit 找出对应的 tree，再对比当前工作区差异，效率非常惊人。

git log 之所以能展示提交历史，也是沿着 commit 对象的 parent 字段往前遍历。每走一步就打印一个 commit，直到遇到没有 parent 的根提交为止。理解这一点后，你就明白为什么“没有 parent 的提交”是第一条提交，也明白为什么合并提交会有多个 parent。

4.3 悬空对象、垃圾回收与数据恢复

当一个 commit 不再被任何分支或标签引用时，它就成了悬空对象（dangling object）。对象本身不会被立即删除，它会躺在对象库里“无人认领”，直到 git gc 运行并被清理。这正是我能从 git reset --hard 事故中找回数据的原因：被 reset 丢掉的 commit 仍然作为悬空对象存在。

你可以用：

bash复制git fsck --lost-found

扫描悬空对象。我那次就是从这里找回了丢失的 commit 哈希，然后用 git cherry-pick 或 git merge 把它恢复到分支上。所以，如果哪天你误删了分支或者 reset 过了头，别急着绝望，先查一下悬空对象再说。

5. 双语精译笔记怎么做：我的翻译与验证方法

5.1 术语对照是关键

“双语精译”最麻烦的不是句子翻译，而是术语统一。Git 领域有很多英文术语，国内译法五花八门。我在笔记开头专门留了一页术语对照表，后续所有章节都严格用同一套译法，避免前后不一致。

每次翻译到关键词，我会在原句下面加一行括号备注，比如 “blob（数据对象）”。这样做的好处是，以后再读英文文档时不至于对不上号，看中文笔记又能快速建立概念映射。

5.2 用实操验证代替死记硬背

翻译术语最怕“字面正确但理解错”。比如 “reachable” 这个词，直译是“可达的”，但到底什么叫“可达”？我是在做了 git fsck 实验之后才真正懂的：如果一个对象能从某个分支引用出发、沿着 tree 和 parent 关系被遍历到，那它就是可达的；否则就是不可达的。

所以我的笔记方法很简单：每翻译完一个小节，就开一个临时仓库，把书里的例子原样执行一遍，然后用自己的话在笔记里补充“为什么”。比如原书说“Git 只会增加对象，很少删除对象”，我就在旁边写：因为对象是内容寻址的，删除对象没有收益，反而可能破坏历史；所以 Git 更倾向于保留它们，靠 gc 定期清理。

这套流程下来，笔记虽然写起来慢，但每一条都有实操支撑，不是抄书。

5.3 翻译时容易踩的坑

翻译 Git 英文教材有几个常见坑。第一个是长句拆解，英文喜欢用从句堆出长句，直译成中文会特别拗口，我的做法是把长句拆成两三个短句，再加一个括号补充原文结构。第二个是命令参数，原文里的 --stdin、--lost-found 这类参数不能翻译，我一般会单独加一行命令说明。

第三个坑是版本差异，Git 官方文档会随版本变化调整命令行为，原书基于某个版本写的，可能和你本机版本有出入。我在笔记里遇到这种情况，会标注“当前测试版本为 Git 2.x，实测结果如下”，避免读者把旧行为当成新行为。

6. 常见问题速查与避坑经验

6.1 “fatal: Not a valid object name” 怎么办

这个报错很常见，通常是哈希值写错了，或者对象真的不存在。我的排查步骤是：

1. 先确认哈希是否完整，Git 允许输入最短 4 位的哈希前缀，但太短可能产生歧义。
2. 用 git cat-file -t <hash> 看类型，如果报错说明对象不存在。
3. 确认对象是否被 gc 清掉，如果是悬空对象且已被清理，那就真的找不回来了。

在日常操作里，这个报错大多是复制哈希时漏了字符，或者粘贴到了 commit 消息里的不完整哈希。

6.2 loose object 和 packed object 有什么区别

对象库里的对象有两种形态：松散对象（loose object）和打包对象（packed object）。松散对象就是单个 zlib 压缩文件，直接存放在 .git/objects 下；打包对象是多个对象被打进一个 pack 文件里，存放于 .git/objects/pack 目录。

随着提交数量增加，松散对象越来越多，Git 会通过 git gc 把内容相同或相近的对象打包压缩，节省磁盘空间。用 git count-objects -v 可以查看统计信息。我在测试仓库特意跑了一次 git gc，发现很多对象从“松散”变成了“打包”，对象库体积明显变小。

6.3 误删分支后如何从对象库找回提交

流程其实很简单，前提是提交对象还没被 gc 清理。步骤如下：

bash复制git fsck --lost-found

这会列出所有悬空对象，包括 commit、tree、blob 和 tag。重点是找 commit 类型的悬空对象：

bash复制git fsck --lost-found | grep commit

拿到 commit 哈希后，可以用 git show <hash> 确认是不是你要找的提交，确认无误后：

bash复制git branch recover <hash>

这样就创建了一个新分支指向这个提交，内容全部回来了。注意，如果误删后你继续提交了多次，gc 还跑过，找回的概率就会下降，所以发现误删后尽量别急着操作其他大命令。

6.4 哈希冲突真的需要担心吗

每次聊到 SHA-1，总会有人问“会不会有哈希冲突”。理论上存在两个不同内容算出同一个哈希的可能，但在实际工程中概率极低，低到 Git 官方也认为不需要为常规开发担心。我做笔记时的处理方式是：把这个问题作为“了解即可”的内容，详细解释 SHA-1 的碰撞代价和 Git 社区的态度，但不建议读者在生产环境里过度担忧。

个人体会是，对象模型这东西，光看文档真的容易睡过去，但只要你愿意花半小时亲手拆解一次，后面的很多命令都会自动“通”了。我就把这个小实验记在了翻译笔记的每一章前面，每次复习都重跑一遍，熟得不能再熟。