【Git 内部原理】`.git` 是怎么记住所有版本的

​ 每次 git commit，Git 都说"已记录"。但你有没有想过：改了几十次、几百次，Git 是怎么全记住的？难道每次提交，它都复制一份完整项目？

​ 这篇文章不讲命令，也不背概念。 我们直接打开 .git 文件夹，看 Git 到底存了什么。读完你会明白三件事：

• 为什么 Git 几乎不会变慢
• 为什么分支创建几乎是瞬间完成
• 为什么 Git 能精确还原任何历史版本

一、.git 文件夹里有什么

​ 当你执行 git init，项目根目录会多出一个 .git 文件夹。这个文件夹就是 Git 的全部家当。如果删掉它，相当于告诉 Git：“我从来没有版本历史。”

​ 如果只看关键部分，结构大致如下：

.git/
├── objects/     ← 所有版本数据都存在这里
├── refs/        ← 分支和标签的指针
├── HEAD         ← 当前在哪个分支
└── config       ← 仓库配置（比如 remote 地址）

• 你可以在任意 Git 仓库里自己看一眼：

  tree .git -L 1
  

​ 会列出 .git 下的所有一级目录和文件，和上面的结构一一对应。

1.1 objects/：所有版本数据的仓库

最重要的目录，Git 记住所有版本的秘密全在这里。

​ 这是 .git 里最核心的目录。你提交过的每一份文件内容、每一次目录结构、每一个 commit，全都以对象的形式存在这里。 后面几节会详细讲 Git 是怎么组织这些对象的。

​ 你可以进去看看：

ls .git/objects/

​ 会看到一堆两位字母的文件夹（如 3a、f2），这些是对象哈希值的前两位，Git 用它来分散存储，避免单个目录下文件太多。

1.2 refs/：分支和标签的指针

​ refs/ 里存的是引用，本质上就是一个个小文件。

​ 可以看到，每个文件里只写了一行 commit 哈希值。

cat .git/refs/heads/main
9cf71a0e00a25a56c416113ce1a66c6c247aa2bf

​ 这就是 main 分支的"指针"，它指向这个分支最新的一次 commit。你每次提交，Git 就把这个文件里的哈希值更新成新的 commit。

​ 标签也类似，存在 refs/tags/ 下。

1.3 HEAD：你现在在哪

​ HEAD 是一个特殊的文件，记录当前工作在哪个分支上：

cat .git/HEAD
ref: refs/heads/main

​ 意思是"我现在在 main 分支"。如果你 git checkout 到某个具体的 commit（而不是分支），HEAD 会直接存那个 commit 的哈希值，这就是所谓的"detached HEAD"状态。

1.4 config：仓库级别的配置

​ 这个文件存的是只对当前仓库生效的 Git 配置，比如远程仓库的地址：

cat .git/config

​ 你会看到类似 [remote "origin"] 和 url = ... 这样的内容。git remote add 其实就是在往这个文件里写东西。

​ 它和全局的 ~/.gitconfig 是分开的。仓库级配置优先级更高，会覆盖全局配置中的同名选项。

二、Git 存东西的方式：快照，不是差异

​ 很多人以为 Git 记录的是"每次改了什么，例如这次改了哪几行代码"（差异），其实不是。Git 记录的是每次提交时项目的完整快照（snapshot）。

​ 听起来很浪费？别急，Git 有个聪明的设计：相同内容只存一份。

2.1 举例

​ 假如有一个项目，里面有三个文件：

README.md
app.py
config.yaml

• 两次commit

  • 第一次 commit，Git 把三个文件的内容都存进 objects/。第二次 commit，你只改了 app.py。

• Git 会怎么做？

  • README.md 没变 → 不存，直接指向上次那份
  • config.yaml 没变 → 不存，直接指向上次那份
  • app.py 变了 → 存一份新的

  所以虽然 Git 记录的是"完整快照"，但没变的文件零开销，只有真正改了的文件才会占空间。

左边是很多版本管理工具的做法，只记录每次的改动（diff）；右边是 Git 的做法，记录完整快照，但没变的文件不重复存储，直接指回原来那份。

三、三种积木：blob、tree、commit

​ Git 的 objects/ 里只有三种东西，像三块积木，搭起了整个版本历史。

3.1 blob：文件内容

​ 每个文件的内容会被存成一个 blob（Binary Large Object）。注意，blob 只存内容，不存文件名。如果两个文件内容完全一样？Git 只存一个 blob，不管它们叫什么名字。

3.2 tree：目录结构

​ tree 记录的是"哪个文件名对应哪个 blob"，相当于一张目录清单：

README.md  → blob-A
app.py     → blob-B
config.yaml → blob-C

​ 如果有子文件夹，tree 里还会嵌套 tree。

3.3 commit：一次快照

​ commit 把这些都串起来。 一个 commit 包含：

• 指向一个 tree（这次提交时项目长什么样）
• 指向父 commit（上一次提交是谁）
• 作者、时间、提交信息

​ commit 指向 tree，tree 指向 blob，三层结构各司其职。commit 记录"谁在什么时候提交的"，tree 记录"项目有哪些文件"，blob 记录"文件里写了什么"。

四、用一个例子串起来

​ 假设你做了两次提交，第二次只改了 app.py。

• 第一次 commit

  commit-1
    └── tree-1
          ├── README.md  → blob-A
          ├── app.py     → blob-B
          └── config.yaml → blob-C
  

• 第二次 commit：

  commit-2（父节点 → commit-1）
    └── tree-2
          ├── README.md  → blob-A   ← 同一个 blob，没有重新存
          ├── app.py     → blob-D   ← 新 blob，内容变了
          └── config.yaml → blob-C   ← 同一个 blob
  

  进行了两次 commit，objects/ 里一共只有：

对象	数量	说明
commit	2 个	每次提交一个
tree	2 个	目录结构变了（app.py 指向不同 blob）
blob	4 个	A、B、C、D，其中 A 和 C 被两个 tree 共享

​ 一共 8 个对象。如果"每次都复制一份"需要 6 个 blob，现在只要 4 个。文件越多、改动越少，这个优势越明显。

两次提交产生了两个 commit 和两个 tree，但 blob-A（README.md）和 blob-C（config.yaml）因为内容没变，被两个 tree 共享，这就是 Git "快照但不浪费"的关键。

五、项目越来越大怎么办

​ 靠上面的"内容去重"已经省了很多空间，但项目跑久了对象还是会越来越多。Git 还有两招：

• 压缩： 每个对象存入时会用 zlib 压缩。代码都是文本，压缩率很高，实际占用比原始文件小得多。

• 打包（packfile）： 当松散对象积累太多时，Git 会自动把它们打包成 .git/objects/pack/ 下的 packfile。打包时 Git 会计算相似对象之间的增量差异，只存"和上一版的区别"，进一步压缩。

  你不需要手动触发这些，git push 和 git gc 时 Git 会自动处理。

  

Git 先把每个对象单独压缩存放（松散对象），积累多了就自动打包成 packfile，利用相似对象之间的增量差异进一步节省空间。

六、动手看一看

​ 前面讲了这么多概念，不如自己动手验证一下。找一个有过提交记录的 Git 仓库，跟着下面的步骤操作。

​ 我们会用到一个底层命令 git cat-file。平时用不到它，但它是查看 Git 对象内容的万能工具，给它一个对象的哈希值（或者 HEAD 这样的引用），它就能把对象的内容打印出来。

6.1 Step1：查看当前commit的内容

# 看当前 commit 的内容
git cat-file -p HEAD

​ HEAD 指向当前分支的最新 commit，所以这条命令会打印出这个 commit 对象的内容。输出大致长这样：

​ 可以看到：commit 里记录了一个 tree 哈希值（这次提交时项目的目录快照）、parent（上一次 commit）、以及作者和提交信息。和之前介绍的完全一致。

6.2 Step2：查看tree

​ 把上一步输出中 tree 后面的哈希值复制过来。-p 参数的意思是"pretty-print"，让输出更易读。

git cat-file -p <tree哈希值>

​ 这条命令打印的是目录快照，也就是提交时项目根目录下有哪些文件和子目录。输出类似：

​ 每一行就是一个条目：文件对应 blob，子目录对应另一个 tree。100644 是普通文件的权限，040000 是目录。

6.3 Step3：看blob里有什么

​ 再从上一步的输出中挑一个 blob 的哈希值：

git cat-file -p <blob哈希值>

​ 这里我们选择app.py对应的blob的哈希值，查看对应的文件内容：

​ 这次输出的就是文件的原始内容，一字不差。blob 就是这么简单。因为它只存内容，不存文件名（文件名记在 tree 里）。

​ 从 commit 到 tree 到 blob，可以一层层追下去。commit 告诉你"谁在什么时候提交了什么"，tree 告诉你"项目有哪些文件"，blob 告诉你"文件里写了什么"。这就是 Git 存储的全貌，没有其他魔法。

七、总结

• .git/objects/ 是 Git 的核心仓库，所有版本数据都在这里
• Git 记录的是完整快照，但相同内容只存一份，没改的文件零开销
• 三种对象各管一件事：blob 存内容、tree 存目录、commit 存快照
• 项目再大也不怕：zlib 压缩 + packfile 增量打包，Git 会自动管理空间

下次再 git commit 的时候，你就知道 Git 在背后做了什么了，不是复制粘贴，而是精打细算地存了一个快照。