内容摘要：打开 Git 的源码仓库，第一眼看到的不是代码，而是一堆让人头皮发麻的目录名。`builtin/`、`refs/`、`object-store/`、`reftable/`——这些命名带着一种老派 C

打开 Git 的源码仓库，第一眼看到的不是代码，而是一堆让人头皮发麻的目录名。`builtin/`、`refs/`、`object-store/`、`reftable/`——这些命名带着一种老派 C 程序员的直白。Linus 当年写第一版 Git 只用了十天左右，但那个粗糙的原型经过二十年演化，已经变成一棵根系极深的树。你如果从 `main.c` 开始读，会很快撞上 `cmd_main()`，然后被 `handle_builtin()` 拽进一个巨大的命令分发表。这就是 Git 的入口逻辑：它本质上是一个“多合一”的二进制文件，靠第一个参数决定自己变成 `git commit` 还是 `git push`。

我刚开始翻源码时最困惑的是 `object-store/` 这个目录。它不叫 `objects/`，也不叫 `odb/`，偏偏用了“store”这个词。后来才明白，Git 把对象存储抽象成了一层可插拔的后端。松散对象、packfile、多包索引、commit-graph，全塞在这下面。`packfile.c` 有七千多行，光解析 pack 头的函数就分了 v2 和 v3 两个版本。读这段代码会有种错觉：你在看一个文件格式的考古现场。每个偏移量、每个 varint 编码，都带着“当年为了性能不得不这么干”的痕迹。

真正让我停下来想了很久的是 `refs/` 目录。引用（reference）在 Git 里就是“某个 SHA-1 或 SHA-256 的别名”，但实现上它分成了 files backend、reftable backend 和 packed backend。`refs/files-backend.c` 里处理 `HEAD` 的代码非常小心——因为 `HEAD` 可以是指向分支的符号引用，也可以直接指向一个 commit。这种灵活性让 `git checkout` 的行为变得微妙。你删掉 `.git/HEAD`，Git 就不知道自己在哪个分支上，但它仍然能通过 `git log` 读历史。源码里对这种情况的处理不是报错，而是回退到“detached HEAD”状态。

另一个有意思的地方是 `diff.c`。Git 的 diff 算法不是简单的 Myers 算法，而是带了很多启发式优化。比如 `--patience` 和 `--histogram` 两种模式，源码里用不同的结构体来管理行匹配。`xdiff/` 目录下全是这类东西，C 代码写得像数学论文。我试着改过 `xdl_change_compact()` 里的一个阈值，结果发现同一个仓库的 diff 输出从 200 行变成了 180 行——少掉的那 20 行其实是“看起来像移动”的块。这种细节在文档里根本不会提，只有读源码才能碰到。

构建系统也值得说一句。Git 用 Makefile，不是 CMake，也不是 Meson。`config.mak.uname` 里针对不同 Unix 变种写了大量条件判断。你在 macOS 上编译，它会自动启用 `HAVE_BSD_SYSCTL`；在 Linux 上则用 `HAVE_PTHREAD`。这种“老派”做法让移植变得麻烦，但也让源码保持了极高的可读性——没有自动生成的配置头文件，所有宏都在你眼皮底下。

读 Git 源码最大的收获不是学会写 C，而是理解了一个版本控制系统的“最小必要复杂度”。比如 `commit.c` 里解析 commit 对象的函数只有一百多行，但处理了 author、committer、gpgsig、mergetag 四种头字段。它不依赖任何第三方库，连 SHA-1 都是自己实现的（`sha1dc/` 那个目录是为了防碰撞攻击后加的）。这种自包含的设计让 Git 能在几乎任何环境里跑起来，代价就是源码里到处是 `#ifdef` 和手写的字节序转换。

如果你打算读 Git 源码，别从 `builtin/commit.c` 开始。先看 `object.h` 和 `commit.h`，把对象模型搞清楚。然后跳到 `refs.c` 看引用怎么解析。最后再回头看 `builtin/` 里的命令实现，你会发现那些看似复杂的选项解析，其实只是在调用底层 API。Git 的源码不优雅，但很诚实——每个函数都在告诉你它到底在干什么，没有多余的抽象层。