Git内部原理：.git目录结构、对象存储与引用机制
说实话，很多开发者用Git好几年，却从没打开过.git文件夹看一眼。我刚开始也是这样——直到有一次仓库莫名其妙坏了，我才意识到，不懂底层原理，出了问题只能干瞪眼。
今天我们就来掀开Git的引擎盖，看看它到底是怎么工作的。你想想看，Git为什么这么快？为什么能离线操作？答案都藏在.git目录里。
.git目录结构：Git的心脏
每个Git仓库根目录下都有个.git文件夹。用ls -la看看，里面大概长这样：
.git/
├── HEAD
├── config
├── description
├── hooks/
├── info/
├── objects/ # 对象存储，核心中的核心
│ ├── info/
│ └── pack/
├── refs/ # 引用，指向特定提交
│ ├── heads/
│ ├── tags/
│ └── remotes/
└── index # 暂存区嗯，这里要注意：objects和refs是最重要的两个目录。前者存数据，后者存指针。我有个同事曾经误删了objects目录，结果整个仓库的历史全丢了——所以，千万别手贱。
对象存储：Git的四种基本对象
Git本质上是一个内容寻址文件系统。什么意思？就是每个文件内容都会计算一个SHA-1哈希值，然后用这个哈希值作为文件名存起来。
Git有四种对象：blob、tree、commit、tag。我画了张图帮你理解它们的关系：
1. Blob对象：存文件内容
Blob就是"Binary Large Object"的缩写。说白了，它只存文件内容，不存文件名。你想想看，如果两个文件内容一模一样，Git只会存一份blob——这就是Git去重的基本原理。
关键点：Blob只存内容，不存元数据（文件名、权限等）。文件名存在tree对象里。
我在项目中遇到过一个问题：一个大型项目里有很多重复的配置文件，每次提交都很大。后来发现Git其实只存了一份blob，只是多个tree对象引用了它。嗯，Git比我想象的聪明多了。
2. Tree对象：存目录结构
Tree对象相当于一个目录清单。它记录了：
- 每个子条目是blob还是tree
- 文件名
- 文件权限（100644普通文件，100755可执行文件）
- 指向的SHA-1哈希值
你可以用git cat-file -p查看一个tree对象的内容：
$ git cat-file -p master^{tree}
100644 blob a1b2c3d4 index.html
100644 blob e5f6g7h8 style.css
040000 tree i9j0k1l2 images/看到了吗？tree对象里引用了blob和其他tree。这就是Git能表示目录结构的原因。
3. Commit对象：存快照
Commit对象是Git的"时间胶囊"。它记录了：
- 指向一个tree对象（项目快照）
- 父commit的哈希（第一个提交没有父节点）
- 作者信息（姓名+邮箱+时间戳）
- 提交信息
用git cat-file -p HEAD看看：
$ git cat-file -p HEAD
tree 4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b
parent 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
author Zhang San <zhangsan@example.com> 1699000000 +0800
committer Zhang San <zhangsan@example.com> 1699000000 +0800
Initial commit: add index.html and style.css我个人习惯用git log --oneline --graph看提交历史，但想深入调试时，cat-file才是神器。
4. Tag对象：打标签
Tag分两种：轻量标签和附注标签。轻量标签就是个指针，附注标签才是一个完整的对象。
附注标签存了：
- 标签指向的commit
- 标签名
- 打标签的人
- 标签信息
- 可选：GPG签名
我的建议：发布版本时用附注标签（git tag -a v1.0 -m "Release v1.0"），临时标记用轻量标签。我曾经因为用了轻量标签标记生产版本，结果回滚时找不到详细信息，折腾了半天。
引用（Refs）：Git的指针系统
引用就是指向commit的指针。没有引用，你就得记住那一长串SHA-1哈希——谁记得住啊？
引用分三类：
| 引用类型 | 存储位置 | 作用 |
|---|---|---|
| 分支引用 | refs/heads/ |
指向分支的最新commit |
| 标签引用 | refs/tags/ |
指向特定commit或tag对象 |
| 远程引用 | refs/remotes/ |
跟踪远程仓库的分支状态 |
打开refs/heads/main文件，里面就一行：
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0就这么简单。一个文件，一个哈希值。Git的分支其实就是个可移动的指针。
注意：HEAD是一个特殊的引用，它指向当前所在的分支。查看.git/HEAD，里面写的是ref: refs/heads/main。如果处于分离头指针状态，HEAD会直接指向一个commit哈希。
包文件：Git的压缩机制
你有没有好奇过，Git仓库用久了，objects目录里文件越来越多，会不会爆炸？
答案是：Git会定期做"垃圾回收"（gc），把松散对象打包成包文件（packfile）。
包文件存在objects/pack/目录下，包含：
.pack文件：存压缩后的对象数据.idx文件：索引，快速定位对象在pack中的位置
Git的打包算法很聪明。它不会存每个文件的完整副本，而是存差异（delta）。比如你改了某个文件的几行代码，Git只存改动部分，而不是整个新文件。
手动触发打包：
$ git gc --aggressive --prune=now避坑指南：我曾经在一个大项目里频繁提交大文件，结果objects目录膨胀到2GB。跑了一次git gc后，压缩到300MB。但要注意，--aggressive很耗CPU，建议在空闲时执行。
对象存储的完整流程
当你执行git add和git commit时，背后发生了什么？
- git add：把文件内容压缩，计算SHA-1哈希，存到
objects/目录（blob对象）。同时更新index文件（暂存区）。 - git commit：先根据暂存区创建tree对象，再创建commit对象指向这个tree。最后更新分支引用指向新commit。
整个过程都是本地操作，不需要网络。这就是Git快的原因。
用git hash-object可以手动体验一下：
$ echo "hello git" | git hash-object --stdin -w
3b18e512dba79e4c8300dd08aeb37f8e728b8dad这条命令把"hello git"存成了blob对象，返回了它的哈希值。去objects/3b/目录看看，你能找到这个文件。
总结一下：Git的对象存储模型其实不复杂。blob存内容，tree存目录，commit存快照，tag存标记。引用就是指针，包文件就是压缩包。理解了这些，Git对你来说就没有秘密了。
下次遇到Git问题，别急着百度。打开.git目录看看，用cat-file查查对象内容，你可能会发现问题的根源。我这些年排查过的Git疑难杂症，十有八九都是靠这个思路解决的。