从对象层理解Git：blob、tree、commit与tag的底层原理-代码聚汇网

从对象层理解Git：blob、tree、commit与tag的底层原理

神秘巨星z·2026-08-29·阅读 22 GEO检测（免费）

Git对象模型blob

|难度：普通|阅读约 36 分钟

1. 为什么我要从对象层去理解Git

1.1 只学命令的问题

我在带团队的时候发现一个规律：很多人用Git用了一两年，日常命令非常熟练，add、commit、push、pull、merge、rebase玩得飞起，可是一旦遇到"分支误删恢复""detached HEAD 状态""提交历史被改写后怎么找回原始内容""仓库为什么突然几个G"这类问题，就直接懵了，只能靠搜索引擎救命。

问题出在哪？出在大多数人把Git当成一个"黑盒工具"来用，只知道"输入什么命令能达成什么效果"，完全不知道命令背后到底做了什么。这就像你天天开车，却完全不懂发动机原理——正常情况下没问题，可一旦仪表盘报警，你连该不该继续开都不知道。

我真正开始理解Git，是从一次事故开始的。当时团队里有人执行了git reset --hard想回退一个错误的合并，结果连带着把别人刚提交的几个commit一起给回退了。大家围在屏幕前急得不行，远程仓库虽然有一份，但本地有几个还没push的提交怎么办？后来我用git reflog找到了那些"丢失"的commit，挨个恢复，才把这锅给补上。这件事之后我意识到：Git的命令只是表象，对象模型才是真相。

1.2 对象模型是"答案之书"

Git本质上是一个内容寻址文件系统。你执行的每一个操作，追到最底层，本质上都是在对四种对象做写入、读取、关联和查找：

blob对象：存储文件内容
tree对象：存储目录结构
commit对象：存储一次提交的元信息和快照根节点
tag对象：存储带注释的标签信息

这四种对象构成了Git的全部宇宙。分支只是一个指向commit的"指针"，HEAD只是一个"当前指针"的标记，工作区、暂存区只是对象在不同状态下的投影。

理解这个模型，你就不会再把Git当玄学用了。git commit做了什么？它创建了一个commit对象、一个tree对象、若干个blob对象，然后把分支指针移到新commit上。git branch做了什么？它只是创建了一个新的引用指向当前commit。git checkout做了什么？它只是把HEAD切到另一个引用/commit上，然后把工作区的文件内容替换成对应tree的快照。

所以我一直跟团队的新人说：花一个下午搞懂Git对象模型，比记一百条命令有用得多。这也是这篇博文的初衷——我想把我自己从"背命令"到"懂原理"这整个过程中的理解、实操和踩坑记录下来，给同样卡在Git底层的朋友一条通往"真相"的路。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 四大对象一网打尽：blob、tree、commit、tag到底存了什么

2.1 blob对象：纯粹的内容快照

先看最简单、也最容易被误解的blob对象。很多人以为blob就是文件，其实不对。blob只存储文件内容，不存储文件名、不存储文件的元数据（权限、时间戳等）。

这意味着什么？意味着你把a.txt重命名为b.txt，内容一字不改，Git并不会生成新的blob对象，它只是在一个新的tree对象里记录了"b.txt → 那个已有的blob对象"这个映射关系。反过来，你把两个内容完全不同的文件都命名为a.txt，在同一个提交里它们会对应两个不同的blob。

git hash-object命令可以直接把一个文件的内容写入对象库（加-w参数），并返回这个blob对象的SHA-1哈希值。我们来做个实验，验证一下上面这个说法。

bash复制# 创建一个测试目录
mkdir git-object-lab && cd git-object-lab
git init

# 写入一个文件
echo "hello git" > a.txt
git hash-object -w a.txt
# 输出：8a9dbfae7b7caf6a1d4c3f7f9f0f4a5b6c7d8e9f（实际hash会不同）

这个hash是根据文件内容计算出来的，与文件名完全无关。所以同一个内容，不管它在哪个目录、叫什么名字，git hash-object算出来的hash永远一样。这就是"内容寻址"的含义——对象的"地址"（hash）就是它的"内容指纹"。

2.2 tree对象：目录结构的骨架

tree对象解决的是"目录结构"的问题。它记录了一个目录下有哪些文件（文件名 + blob hash）、有哪些子目录（目录名 + 子tree hash），以及每种条目的访问权限（mode）。

一个tree条目的格式大致是：

text复制100644 blob 8a9dbfae...    a.txt
100755 blob 2b4c5d6e...    run.sh
040000 tree 3f7a90bc...    src

100644是普通文件权限
100755是可执行文件权限
040000代表这是一个子tree（目录）
symlink对应120000

用git ls-tree可以查看任意一个tree对象的内容：

bash复制git ls-tree HEAD
# 例如输出：
# 100644 blob 8a9dbfae...    a.txt

理解tree对象是理解Git快照机制的关键。每次提交保存的不是"差异"，而是一整棵tree——准确地说，是一个完整的目录快照。只是Git在存储时复用了大量未变化的blob和子tree，才让"快照"在存储上很节省。这跟很多人想象中"Git存的是diff"完全不一样，Git存的是快照，差异只是事后算出来的。

2.3 commit对象：元数据与快照的锚点

commit对象是Git对象模型里最上层的结构。它记录了：

一棵tree（本次提交的根目录快照）
一个或多个parent（父提交，第一个提交没有parent，merge提交有多个parent）
author（作者）和 committer（提交者）信息，包括名字、邮箱和时间戳
提交信息（commit message）

用git cat-file -p HEAD看一个真实的commit对象：

text复制tree 6b3f9f4d29d1eb1d64d6a8e0c0a0e1b3f4a5b6c7
parent 8c2a1b3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b
author Zhang San <zhangsan@example.com> 1700000000 +0800
committer Zhang San <zhangsan@example.com> 1700000000 +0800

feat: add git object lab

commit就是Git历史的"链环"。通过parent字段，所有commit串成一条有向无环图（DAG）。分支之所以可以随意创建、合并、回退，本质上就是在这张图上移动指针、增加节点。

一个很容易被忽略的关键点：commit对象一旦创建，它的hash就固定了。如果你改了提交信息（git commit --amend）、改变了父提交或改了快照内容，实际上你是创建了一个全新的commit对象，老的commit对象会被"遗弃"（变成悬空对象）。这就是为什么改写历史会生成一堆孤儿commit。

2.4 tag对象：额外的锚点

tag对象分为两种：轻量标签（lightweight tag）和附注标签（annotated tag）。

轻量标签本质上就是一个引用，直接指向某个commit，不创建独立对象。而附注标签会创建一个独立的tag对象，里面记录了：

指向的commit hash
打标签的人的信息
打标签的时间
标签说明文字

bash复制# 创建一个附注标签
git tag -a v1.0.0 -m "release v1.0.0"
git cat-file -p refs/tags/v1.0.0
# 输出：
# object 6b3f9f4d29d1eb1d64d6a8e0c0a0e1b3f4a5b6c7
# type commit
# tag v1.0.0
# tagger Zhang San <zhangsan@example.com> 1700000000 +0800
#
# release v1.0.0

tag对象的意义在于：它给某个commit提供了一个人类可读的、语义化的永久别名，在大版本发布、里程碑记录等场景中非常重要。从对象模型角度看，tag只是commit的"外层包装"，它不改变commit本身的任何属性。

3. 用底层命令手工"造"一个提交

3.1 准备工作：像工程师一样查看对象

理解了四种对象的概念之后，最有效的巩固方式就是亲手用底层命令（plumbing commands）去重现一次常规提交的过程。很多人只知道git add和git commit这对"高层命令"，却不清楚它们内部到底调用了哪些底层操作。

先了解两个最高频的底层查看命令：

bash复制# 查看对象的类型
git cat-file -t <sha>

# 查看对象的原始内容
git cat-file -p <sha>

-t输出对象类型，-p根据对象类型"人性化"地展示内容。这两个命令我一天能用几十次，排查问题、理解对象关系都靠它们。

另外一个非常实用的底层命令是git rev-parse，它能把各种引用（分支名、标签名、HEAD、reflog表达式）解析成对应的commit hash：

bash复制git rev-parse HEAD
git rev-parse main
git rev-parse HEAD~2

HEAD~2表示HEAD往前数两个提交，Git内部会沿着parent链去解析。这个解析过程本身就是"对象解析"最典型的应用。

3.2 从零构造blob、tree、commit

现在，我们在git-object-lab仓库里，不借助git add和git commit，手动构造一次提交。

第一步，创建两个文件并写入blob对象：

bash复制echo "Hello Git Objects" > README.md
echo "#!/bin/bash" > run.sh
echo "echo 'run'" >> run.sh

# 写入对象库，并拿到各自的blob hash
readme_hash=$(git hash-object -w README.md)
run_hash=$(git hash-object -w run.sh)
echo $readme_hash $run_hash

第二步，创建tree对象。Git的mktree命令可以接受一行行的"mode type hash name"输入来构造tree对象：

bash复制git mktree <<EOF
100644 blob $readme_hash    README.md
100755 blob $run_hash    run.sh
EOF

mktree会输出一个tree对象的hash，这就是当前根目录的快照。

第三步，用commit-tree创建commit对象：

bash复制tree_hash=$(上面的输出)
commit_hash=$(git commit-tree $tree_hash -m "manual commit created by plumbing commands")
echo $commit_hash

这时候，一个commit对象已经被写入了.git/objects目录。你可以用git log看看——由于没有任何分支指向这个commit，git log默认不会显示它。但git log $commit_hash就能看到完整历史。

第四步，让分支指向这个commit：

bash复制git update-ref refs/heads/main $commit_hash
git log --oneline
# 输出：<commit_hash> manual commit created by plumbing commands

至此，我们用纯底层命令完成了一次提交流程。update-ref的作用就是更新引用文件（.git/refs/heads/main）里的hash值，没有任何魔法。

3.3 用`fsck`找"被遗落"的对象

你可能会好奇：那些没有分支引用的commit去哪了？答案是它们还在对象库里，只是成了"悬空对象"（dangling object），等待被垃圾回收（git gc）清理。

用git fsck --lost-found可以列出所有无法通过引用访问的对象：

bash复制git fsck --lost-found
# 输出类似：
# dangling commit 6b3f9f4d29d1eb1d64d6a8e0c0a0e1b3f4a5b6c7

--lost-found除了列出来，还会把悬空的对象内容写到.git/lost-found/目录下。这一招在误删分支后找回提交时至关重要，后面我会专门讲排错场景。

**关键心得**：真正理解"引用只是对象图上的指针"这一点之后，你对Git的恐惧会消失大半。因为不论你的操作多"灾难"，只要对象还在，总有办法找回来。

4. 对象在`.git/objects`里的真实存在形态

4.1 松散对象（loose object）的存储格式

所有对象最终都存放在.git/objects目录下。找一眼这个目录，你会看到一个又一个两位十六进制的子目录：

text复制.git/objects/
├── 6b/
│   └── 3f9f4d29d1eb1d64d6a8e0c0a0e1b3f4a5b6c7
├── 8a/
│   └── 9dbfae7b7caf6a1d4c3f7f9f0f4a5b6c7d8e9f
└── pack/
    └── ...

对象文件名是完整的40位SHA-1哈希，前两位作为目录名，后面38位作为文件名。这样设计的目的是分散目录中的文件数量，避免对象库变成"一个大目录里塞几万个文件"的灾难。

对象内容本身不是明文，而是经过zlib压缩的。你可以亲自解压看看：

bash复制# 用python解压一个对象
python3 -c "
import zlib, sys
with open(sys.argv[1], 'rb') as f:
    data = zlib.decompress(f.read())
    print(data)
" .git/objects/8a/9dbfae7b7caf6a1d4c3f7f9f0f4a5b6c7d8e9f

控制台会输出类似这样的内容：

text复制blob 11\x00Hello Git Objects

注意看格式：第一段是对象类型（blob），中间是内容长度（11），然后是空字节\x00，最后才是原始内容。这就是Git对象内部的序列化协议。

4.2 对象hash是怎么算出来的

一个对象的SHA-1值，不是简单地对文件内容做哈希，而是对"类型 + 长度 + 空字节 + 内容"这个整体做哈希。也就是说：

text复制sha1("blob 11\0Hello Git Objects") = 8a9dbfae7b7caf6a1d4c3f7f9f0f4a5b6c7d8e9f

你可以自己验证：

bash复制python3 -c "
import hashlib
data = b'blob 11\x00Hello Git Objects'
print(hashlib.sha1(data).hexdigest())
"

输出的hash会和git hash-object返回的结果完全一致。这就解释了为什么对象是"内容寻址"的——内容变了，hash必变；内容相同，hash必同。

4.3 packfile：压缩、压缩、再压缩

松散对象存放方便，但时间一久，大量重复内容会导致仓库膨胀。Git会通过git gc（垃圾回收）把松散对象打包成packfile，存放在.git/objects/pack/下：

text复制.git/objects/pack/
├── pack-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.idx
└── pack-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.pack

.pack文件是真正的对象数据，.idx文件是索引，用于快速定位某个hash的对象在.pack里的偏移量。打包时Git会做两层努力：

对每个对象做zlib压缩；
在多个对象之间做增量压缩（delta compression），即只存储两个相似对象之间的差异，版本历史越长、文件修改越频繁，效果越显著。

用git count-objects -v可以查看仓库对象统计：

bash复制git count-objects -v
# count: 8   // 松散对象数量
# size: 12   // 松散对象总大小（KB）
# in-pack: 0 // pack中对象数量
# packs: 0   // pack文件数量
# ...

如果你觉得仓库太大，想知道到底是哪些大占用，可以这样列出对象库中size最大的前10个对象：

bash复制git rev-list --objects --all \
  | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
  | sort -k3 -n -r \
  | head -10

这条命令把仓库里所有可达对象都列出来，按大小排序。一旦你发现某个历史遗留的大文件（比如几年前的视频文件）占了好几百MB，就知道该怎么办了——要么git filter-repo改写历史，要么接受这个仓库天生就大的现实。

补充一个排查技巧：如果某个对象只有hash，你不知道它对应的文件名，git rev-list --objects --all | grep <hash>可以帮你找出名字。

5. refs、HEAD与reflog：对象模型的"导航仪"

5.1 为什么分支只是个指针

在Git对象模型里，分支不被算作对象，它只是.git/refs/heads/目录下一个文本文件，内容是一行commit hash：

text复制# .git/refs/heads/main
6b3f9f4d29d1eb1d64d6a8e0c0a0e1b3f4a5b6c7

创建分支git branch dev，本质就是echo <commit-hash> > .git/refs/heads/dev。切换分支git checkout dev，本质就是把HEAD这个特殊文件的内容改成ref: refs/heads/dev。

所以，Git里面没有任何一个"分支对象"，你看到的所有分支状态，都是"从一个引用出发，沿着commit的parent链遍历出来的历史"。

HEAD文件的内容决定了你当前在哪：

text复制# .git/HEAD
ref: refs/heads/main

这也解释了detached HEAD状态：如果git checkout <commit-hash>，HEAD的内容就是一个具体的hash而不是ref: refs/heads/xx。此时你不在任何分支上，提交会产生新的commit，但没有分支引用指向它——一旦你切走，它就成了悬空对象。

5.2 reflog：引用活动的"黑匣子"

reflog（reference log）记录的是引用在过去一段时间内的变化历史，存储在.git/logs/目录下。只要引用（HEAD、分支）发生变化，就会追加一条记录。

bash复制git reflog
# 输出示例：
# 6b3f9f4 HEAD@{0}: commit: manual commit created by plumbing commands
# 8f2e1a2 HEAD@{1}: commit: feat: add object lab
# ...

HEAD@{n}语法可以引用第n次之前的HEAD状态。git reset --hard HEAD@{1}可以回退到"上一次HEAD所在的位置"——哪怕那次提交后来被reset掉了，只要reflog记录还在，就能找回。

reflog是Git自救的第一道防线。误删分支？git branch <name> <commit-hash>即可恢复。reset错了？git reset --hard HEAD@{1}找回。rebase出问题了？git reflog找到rebase前的commit。

5.3 我的一次真实事故复盘

有一次我在本地给一个项目做大规模重构，连续改了几十个文件，然后手滑在另一个窗口执行了git reset --hard origin/main，本地所有未push的工作全部"消失"。我当时第一反应是心跳漏了一拍，但马上冷静下来，跑了git reflog，看到半小时前有一条commit: refactor: 重构配置模块的记录，hash是a1b2c3d。于是：

bash复制git branch backup-2025-refactor a1b2c3d

一条命令，整个分支回来了，工作区状态也完整恢复。这个过程中我对reflog信任到了骨子里——因为它本质上就是一份"引用变更日志"，只要对象没被git gc --prune=now清掉，数据就在那儿躺着，等着你去捡。

6. 对象解析思路在实战中的三个应用

6.1 场景一：误删分支后找提交

这是最常见的事故。git branch -D foo删掉分支后，很多人以为提交就没了。实际上分支只是引用文件被删了，commit对象还挂在对象库里。

恢复步骤：

bash复制# 1. 在reflog里找到该分支最后一次指向的commit
git reflog | grep foo
# 2. 用commit hash重建分支
git branch foo <commit-hash>

如果reflog历史比较长，可以直接翻找所有悬空提交：

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

然后逐个git show <hash>确认提交内容，找到目标后用git branch <name> <hash>恢复。

6.2 场景二：detached HEAD下的"幽灵提交"

我见过不少同事在detached HEAD状态下提交了一堆代码，切回分支后发现"提交不见了"，急得直跺脚。同样，只要知道HEAD在detached期间指向的commit hash，或者从reflog中找到HEAD@{n}，就能拯救：

bash复制# 先查看reflog，确认detached期间提交的hash
git reflog

# 在提交hash上创建分支
git branch save-detached-work <commit-hash>

# 把这个分支合并回目标分支
git checkout main
git merge save-detached-work

核心心法：你在detached HEAD下提交的commit对象，和普通提交一样躺在对象库里，只是没有引用指向它。给它一个引用，它就回来了。

6.3 场景三：仓库膨胀与敏感对象清理

前面提到的git rev-list --objects --all能帮你定位大文件。而如果你不小心把包含密钥、账号密码的文件提交到了仓库里，光是删除当前文件再提交是不够的——历史提交里仍然存着这个blob对象，任何clone过仓库的人都能通过对象解析找出来。

彻底清理的做法是使用git filter-repo（官方推荐替代filter-branch的工具）：

bash复制# 安装后，删除所有历史中的指定路径
git filter-repo --path secret.txt --invert-paths

# 强制推送到远程（需要团队协作配合，因为这会重写所有历史）
git push --force --all

清完之后执行git gc --prune=now --aggressive，把旧对象从本地对象库中彻底移除。

**安全提示**：记住，任何写进Git历史的内容都不是"删掉文件"就能抹除的。密钥、证书、密码一旦进入对象库，就应当视为已泄露，建议立即轮换。

这一套对象解析的思路，同样适用于".git目录泄露"之类的场景——如果某个站点不小心把.git目录暴露在了公网，攻击者可以通过对象解析逐步还原出源码。所以从防护角度看，生产环境永远不要部署.git目录，尽量用git archive导出干净的源码包，并在服务端配置禁止访问.git路径。

7. 给初学者的几条实操建议

7.1 在真实项目里做"对象解剖"

我建议所有想真正掌握Git的人，花一个下午在自己的测试仓库里做一次"对象解剖实验"：

git init一个新的仓库；
手动执行git hash-object -w、git mktree、git commit-tree、git update-ref，完成一次完整提交；
用git cat-file -t和git cat-file -p查看每个对象的类型和内容；
用git fsck --lost-found验证悬空对象的存在；
用git reflog模拟一次误删分支后的恢复。

这一步做完，你对Git的信任感会完全不同——我不再把它当一个"有神秘力量的黑盒"，而是当成一个数据结构清晰、行为可预测的内容寻址系统。

7.2 几个高频命令的组合记忆

对象解析相关的命令，按使用频率排个序：

命令	作用	使用频率
`git cat-file -p <sha>`	查看对象内容	极高
`git cat-file -t <sha>`	查看对象类型	高
`git rev-parse <ref>`	解析引用到hash	高
`git ls-tree <sha>`	查看tree对象内容	高
`git reflog`	查看引用变更历史	中
`git fsck --lost-found`	找回悬空对象	低但救命
`git hash-object -w`	手动创建blob	学习/调试
`git mktree`	手动创建tree	学习/调试
`git commit-tree`	手动创建commit	学习/调试

7.3 善用`--no-optional-locks`等细节

在自动化脚本里执行Git命令时，很多人会踩一个坑：Git的某些命令（比如git status）默认会尝试获取index.lock等可选锁，在并发环境容易报错。加--no-optional-locks可以避免那些非关键锁的获取，让脚本更稳定。

不过这类选项属于Git命令行的"细节彩蛋"，优先级远不如理解对象模型。我始终认为：先懂模型，再学命令，最后才是技巧。顺序反了，你永远会在各种"奇技淫巧"里打转，模型通了，你自己就能发明技巧。

说到底，Git对象解析不是什么高深莫测的魔法，它只是一套极其朴素的思路：通过内容寻址，把文件、目录、提交、标签全部变成可定位、可引用、可追溯的对象。你在日常工作中遇到的大部分Git问题，追根溯源都能落到"对象在哪里、引用指向谁、历史怎么找"这三个问题上。

如果你刚接触这块内容，建议从git cat-file -p HEAD开始，一层一层往下剥：commit里有tree hash，tree里有blob hash，blob里有纯文本内容。剥完一个提交，你会发现自己对Git的理解已经超过了大半同行。