Git 之所以能够在分布式协作场景中保持高效的版本控制能力，其底层存储引擎的设计功不可没。与传统关系型数据库不同，Git 采用了一种被称为「内容寻址存储」的架构模式，配合精细的增量压缩算法，实现了存储空间与网络带宽的双重优化。理解这些底层机制，不仅有助于在大型单体仓库中排查性能问题，也为设计其他分布式存储系统提供了宝贵的参考范式。
内容寻址存储的核心原理
Git 的对象存储目录 .git/objects/ 本质上是一个键值数据库，其中键是对象的 SHA-1 哈希值，值则是经过压缩的对象内容。这种设计被称为内容寻址存储，其核心思想是：对象的标识符直接由其内容计算得出，而非由用户指定。当你向 Git 仓库提交一个文件时，Git 首先使用 zlib 算法压缩文件内容，然后计算压缩后数据的 SHA-1 哈希值，最后将结果写入 .git/objects/前两位哈希/其余哈希 路径下。
这种设计带来了三个关键的工程收益。第一是天然的去重机制：相同内容的不同文件会指向同一个对象，因为它们的哈希值必然相同。第二是完整性校验：任何对磁盘数据的篡改都会导致哈希值变化，使得损坏可以被自动检测。第三是安全性保障：攻击者无法通过伪造对象来绕过版本历史，因为没有对应内容的有效哈希就无法通过验证。
内容寻址存储的另一个重要特性是其查询模型的简洁性。Git 不需要复杂的索引结构来查找对象 —— 给定一个哈希值，你可以通过简单的路径拼接直接定位到对应的文件。这种「直接映射」的设计在对象数量较少时非常高效，但当仓库规模扩大时，单一目录下的文件数量会成为文件系统的瓶颈。Git 通过将对象分散到 256 个子目录（哈希的前两个十六进制字符作为目录名）来缓解这一问题，使得每个目录下的文件数量保持在可控范围内。
从松散对象到 Packfile 的演进
当仓库规模较小时，每个对象以独立的压缩文件形式存储，这种格式被称为「松散对象」。然而，随着提交历史的增长，松散对象的存储方式会暴露出明显的效率问题。首先是文件系统层面的性能损耗：大量小文件会导致目录遍历变慢，文件系统元数据开销显著增加。其次是存储空间的浪费：源代码的相邻版本之间通常只有少量差异，但松散对象会完整存储每个版本的内容。
Git 引入 Packfile 机制来解决这些问题。一个 Packfile 将多个对象打包到单个二进制文件中，配合索引文件实现快速随机访问。更重要的是，Packfile 引入了增量压缩（Delta Compression）技术：对于内容相似的对象，Git 只存储它们之间的差异部分，而非完整内容。
增量压缩的核心思想可以用一个简单例子说明。假设你的代码仓库中有两个版本的 repo.rb 文件，原始版本为 22044 字节，添加一行注释后变为 22054 字节。在松散对象格式下，这两个版本各占用约 7KB 的磁盘空间（zlib 压缩后）。但在 Packfile 中，Git 可能只存储完整的新版本（约 5800 字节），而旧版本则以增量形式存储 —— 可能只有 9 个字节，因为增量只需要描述「在文件末尾添加一行」这一操作。
Packfile 的增量编码采用一种基于指令的格式。当一个对象被存储为增量时，它包含一系列「复制」和「插入」指令。复制指令告诉 Git 从基对象（Base Object）的哪个位置复制多少字节的数据，插入指令则用于添加全新的数据内容。这种设计允许 Git 表达任意的差异场景，同时保持编码的紧凑性。
Packfile 索引与查找优化
一个 Packfile 由两部分组成：实际的打包数据（.pack 文件）和对应的索引文件（.idx 文件）。Packfile 本身只存储对象数据，不存储对象标识符 —— 这意味着如果要在 Packfile 中查找一个对象，你需要解压并哈希每个对象才能进行比较。为了避免这种线性扫描，索引文件预先计算并存储了所有对象的偏移量信息。
索引文件的核心结构是一个排序后的对象 ID 列表，配合对应的文件偏移量。通过对对象 ID 进行二分查找，Git 可以在 O (log n) 时间内定位到目标对象的位置。进一步的优化是「扇出表」（Fanout Table）：索引文件头部包含 256 个条目，记录以每个可能的首字节开头的对象在主列表中的范围。由于 SHA-1 哈希在空间上均匀分布，扇出表可以将二分查找的范围缩小到原来的 1/256，显著减少了内存页面切换的次数。
当仓库中存在多个 Packfile 时，Git 面临一个新的挑战：按顺序查询每个索引文件的效率太低。为此，Git 引入了多 Packfile 索引（Multi-Pack Index，简称 MIDX）。MIDX 将多个 Packfile 的索引信息合并到单个文件中，使得一次二分查找就能确定对象所在的 Packfile 和在该文件中的偏移量。这一优化对于大型单体仓库尤为关键 —— 没有 MIDX 时，git fetch 可能需要查询数百个索引文件才能定位一个对象。
增量链与工程权衡
Packfile 中的增量关系并非仅限于一层。一个对象可以作为另一个增量对象的基对象，从而形成「增量链」（Delta Chain）。这种设计允许 Git 在存储空间和读取开销之间取得平衡。长链可以进一步压缩存储空间，因为链上的每个对象只需要描述相对于前一个对象的差异；但读取链中间的任意对象都需要依次解包整个链，导致访问延迟增加。
Git 通过 pack.depth 配置参数控制增量链的最大长度，默认值为 50。在创建 Packfile 时，Git 会优先使用最近的对象作为基对象，并将增量链按时间倒序排列。这一策略确保了高频访问的最近版本具有最短的访问路径，而历史版本虽然访问开销较大，但被访问的概率也较低。
另一个关键的工程参数是 pack.window，它决定了在寻找最佳增量基对象时比较的窗口大小。较大的窗口可能找到更好的压缩比例，但计算成本呈二次方增长。git gc 命令默认使用 10 的窗口大小，而 git repack -a 则会使用更大的窗口以获得更优的压缩效果。在实际项目中，这个参数需要根据仓库特性和维护窗口进行调优。
维护策略与实践参数
Packfile 并不是实时更新的 ——Git 会批量处理松散对象，将其打包成 Packfile。这种延迟写入的策略减少了磁盘 I/O 的频率，但也意味着仓库可能在一段时间内处于次优状态。Git 会在 git push、git fetch 和 git gc 等操作时触发打包行为，但主动运行 git gc 仍然是保持仓库健康的重要实践。
对于大型仓库，完整重打包（Full Repack）的成本可能非常高昂 —— 它需要两倍于当前仓库大小的磁盘空间，并且计算时间可能长达数小时。Git 2.33 引入了几何打包（Geometric Repacking）策略，通过 git repack --geometric 命令可以在不完全重写整个仓库的情况下，逐步优化 Packfile 的分布。该策略确保 Packfile 的大小呈几何级数增长，使得任何对象在 log₂(最大 Pack / 最小 Pack) 次查找后必然被找到。
增量打包任务（Incremental Repack Task）是另一个值得关注的优化。它将小于阈值的 Packfile（默认为 2GB）分批打包，而不会触及已存在的大型 Packfile。这一策略特别适合作为后台维护任务持续运行，避免了维护操作对开发工作流的阻塞。结合 git maintenance start 启用后台维护后，增量打包会自动在系统空闲时执行。
理解这些底层机制后，你可以通过以下实践优化仓库性能：使用 git count-objects -v 监控松散对象的数量；通过 git verify-pack -v 分析 Packfile 中的增量分布；调整 core.deltaBaseCacheLimit 控制缓存的基对象数量；对于超大型仓库，启用 MIDX（Multi-Pack Index）可以显著提升对象查找性能。
资料来源：Git 官方文档、GitHub Blog（Derrick Stolee, 2022）。