对于每日使用 Git 的开发者而言，版本控制系统的内部机理往往像一个黑盒。git add、git commit、git checkout 这些命令背后究竟发生了什么？从零实现一个 Git 核心功能的实践，能够将这种模糊的认知转化为清晰的理解。这一过程不仅仅是代码堆砌，更是一系列工程决策的权衡与取舍。
对象模型的分层设计
Git 的核心抽象可以概括为三层对象结构的组合：blob 对象存储文件内容、tree 对象描述目录结构、commit 对象记录快照信息。这种分层设计的精妙之处在于职责分离 ——blob 只关心数据本身，tree 负责组织关系，commit 提供时间维度的锚点。在实现过程中，首先需要决定的是这三种对象的序列化格式。原版 Git 采用简洁的文本格式存储 tree 和 commit，tree 对象的每一行包含模式、文件名和对象哈希值的组合，而 commit 对象则通过换行分隔的键值对记录树哈希、父提交、作者和时间戳等元信息。
从零实现时，一个常见的决策点在于是否保持这种文本格式的可读性。选择保留意味着可以方便地使用 cat-file -p 直接查看对象内容，但也增加了解析的复杂性；选择二进制格式则能提升读写性能，却牺牲了调试便利性。大多数教育性实现倾向于保留文本格式，因为这更符合 "理解 Git" 的初衷 —— 让开发者能够直观地观察对象的内部结构。
内容寻址存储的哈希策略
内容寻址存储是 Git 区别于传统版本控制系统的重要特征。每一个对象通过其内容的 SHA-1 哈希值（现逐步迁移至 SHA-256）作为唯一标识，这意味着相同的内容必然产生相同的对象标识，从而天然实现了去重。原版 Git 将对象存储在.git/objects/ 目录下，按哈希值的前两位字符创建子目录，其余字符作为文件名，这种分桶策略既避免了单一目录下文件过多导致的文件系统性能问题，也保持了对象查找的 O (1) 复杂度。
实现内容寻址存储时，需要考虑哈希计算的时机。一种做法是在写入时实时计算哈希并作为对象路径，这要求对象内容必须先于路径确定；另一种做法是先写入临时文件，计算哈希后再移动到正确位置。后者能够保证写入操作的原子性 —— 如果写入过程中断，临时文件可以被清理而不会留下不完整的对象。原生 Git 采用了类似后者的思路，通过对象写入的原子性保证仓库的一致性。
存储格式与压缩策略
原版 Git 使用 zlib 进行对象压缩，并支持 packfile 机制进行增量存储。当对象数量较少时，Git 将每个对象单独压缩存储在松散对象文件中；当仓库规模增大时，Git 会将多个对象打包成 packfile，使用差分编码（delta encoding）大幅减少存储空间。packfile 中包含对象引用链，每个被引用的对象只需存储一次，后续的增量修改通过指向基准对象的指令描述。
从零实现时，packfile 的完整实现是一个相当复杂的工程挑战，涉及 delta 搜索算法、索引文件格式以及对象解析顺序等多个难点。一个务实的策略是先实现松散对象的读写，待核心功能稳定后再逐步添加 packfile 支持。对于学习目的的实现，甚至可以完全跳过 packfile—— 这虽然无法处理大规模仓库，但足以理解 Git 的核心对象模型。在实际实现中，压缩级别（zlib compression level）的选择也需要权衡：更高的压缩比意味着更小的存储空间和更长的 CPU 时间，对于频繁写入的场景可能需要调低压缩级别以提升响应速度。
暂存区与索引的设计考量
暂存区（staging area）是 Git 工作流中的核心概念，它隔离了 "已修改" 与 "已暂存" 两种状态，使得增量提交成为可能。原版 Git 通过索引文件（.git/index）记录暂存区的当前状态，这是一个经过精心设计的二进制格式，支持快速的状态比较和文件查找。索引文件的核心数据结构是一个按路径排序的条目数组，每个条目包含文件名、对象哈希、文件大小和最近修改时间等信息，这种设计使得 git status 可以快速判断哪些文件发生了变化。
实现索引功能时，一个关键的设计决策是何时更新索引。一种方案是在每次文件修改后立即同步更新索引，这保证了索引的实时性但增加了 IO 开销；另一种方案是延迟更新，仅在用户执行 git add 时才刷新索引，这减少了不必要的磁盘写入但增加了状态管理的复杂性。原版 Git 采用了折中方案：git add 显式更新索引，而 git status 通过比较索引与工作区文件的 mtime 和 size 来快速判断变更，避免了每次都重新扫描文件内容。
工程实践中的权衡
从零实现 Git 的过程，本质上是在重复 Git 设计者当年的决策路径。每一个看似简单的选择背后都隐藏着复杂的权衡：可读性与性能、简洁性与扩展性、实现难度与功能完整性。这些决策并非绝对的对错之分，而是特定场景下的最优解。例如，教育性实现可以为了可读性牺牲打包功能，而生产级实现则必须完整支持 packfile 以应对大型仓库。
理解这些设计决策的来龙去脉，对于日常使用 Git 也有实际帮助。当开发者明白为什么分支切换如此快速（因为只是更新 HEAD 指针而非复制对象），为什么合并冲突能够被检测（因为比较的是 tree 对象的共同祖先），为什么 force push 可能引发问题（因为覆盖了他人引用的 commit 对象），就能更自信地处理版本控制中的各种场景。从零实现的经历，最终会转化为对分布式版本控制系统本质的深刻理解。
参考资料
- Write yourself a Git! (https://wyag.thb.lt/)
- Building Git from Scratch in Go (https://dev.to/uthman_dev/building-git-from-scratch-in-go-what-i-learned-about-version-control-internals-4dih)