software

git clone 的真实工作原理：深入探讨 Git 对象数据库

发布: (2025年12月11日 GMT+8 14:22)
7 min read
原文: Dev.to

Source: Dev.to

git clone 实际做了什么

Git 会执行以下步骤：

  1. 与远程协商，发现可用的引用（分支、标签）。
  2. 下载完整的对象图——所有可从这些引用到达的提交、树和 blob，采用高效的打包和增量压缩。
  3. 将这些对象写入 .git/objects/pack/，设置本地引用和 HEAD，随后从已检出的提交的根树中签出工作目录。

本质上：

clone = copy the object graph + set references + checkout the working tree

Git 对象模型：核心构件

Git 是一个内容寻址的数据库，而不是传统的文件系统。每个文件、目录、提交和标签都以不可变对象的形式存在，由加密哈希（SHA‑1 或 SHA‑256）标识。这使得 Git 的数据模型具备防篡改、去重和可验证的特性。

类型用途包含内容
Blob文件数据原始字节和一个头部
Tree目录快照子项的模式、名称和对象 ID
Commit快照元数据作者、提交信息、父提交、根树
Tag带注释的引用标签信息和指向的对象

对象图

commit C
│  tree -> T_root
│            ├── mode 100644 "README.md" -> blob B1
│            ├── mode 100755 "build.sh"  -> blob B2
│            └── mode 040000 "src"       -> tree T_src
│                                                ├── "main.go" -> blob B3
│                                                └── "util.go" -> blob B4
│
└── parent -> commit P
               │ tree -> T_prev
               └── parent -> ...

关键概念

  • 提交指向一个树对象，树对象代表仓库的一个快照。
  • 树指向 blob（文件）或其他子树（目录）。
  • 提交通过父引用形成有向无环图（DAG）。
  • 相同的内容会产生相同的哈希，Git 会自动复用对象。

git clone 与远程的通信方式

克隆操作是 Git 客户端与远程服务器之间的结构化对话。

广告阶段

远程服务器会公布：

  • 可用的引用（例如 refs/heads/main、refs/tags/v1.0）
  • 支持的能力（例如 side-band、ofs-delta、multi_ack）

协商阶段

客户端回应：

  • Wants：它需要的提交
  • Haves：它已经拥有的提交（用于增量克隆）

服务器分析提交图，确定客户端缺少的对象。

打包文件传输阶段

服务器：

  • 收集所有从请求的提交可达的对象
  • 对它们进行增量压缩以提高传输效率
  • 将单个 .pack 文件流式传输给客户端

客户端将该包写入：

.git/objects/pack/pack-XXXX.pack
.git/objects/pack/pack-XXXX.idx

协议流程概览

Client                          Server
  |          ls-refs              |
  |------------------------------>|
  |       refs + capabilities     |
  ||
  |           have(s)             |
  |------------------------------>|
  |        ACK/NAK + pack         |
  | "ref: refs/heads/main"
├── config               -> [remote "origin"]
├── refs
│   ├── heads/main
│   ├── remotes/origin/main
│   └── tags/
└── objects
    ├── pack/
    │   ├── pack-XYZ.pack
    │   └── pack-XYZ.idx
    └── info/

关键组件

  • .git/objects/pack：打包的对象存储
  • .git/refs/heads：本地分支
  • .git/refs/remotes/origin：远程跟踪分支
  • .git/index：暂存区缓存
  • .git/HEAD：指向当前分支的符号引用

Git Checkout 如何创建文件

检出过程把数据库对象转换为真实文件：

  1. 读取 HEAD → 解析分支 → 解析提交
  2. 读取提交的根树
  3. 遍历树并把每个 blob 写入工作目录
  4. 在索引中缓存路径‑blob 映射
HEAD -> refs/heads/main -> commit C -> tree T_root
                                   |-> blobs -> files
Working tree  base OBJ_A]
[OBJ_C full]
...
[checksum]

该机制显著降低了磁盘占用和网络传输量。

数据完整性与安全性

  • 每个对象的哈希覆盖其头部和内容——任意字节的更改都会导致哈希变化。
  • 提交通过父哈希相连，形成可验证的信任链。
  • git fsck、git verify-pack 等工具可以检测损坏。
  • 已签名的提交和标签提供了密码学层面的真实性。

Git 的安全模型是数学上的：完整性由哈希链接保证。

示例：最小仓库流程

  1. 初始提交 C0 → 树 T0 → blob B1（README）
  2. 下一次提交 C1 → 修改 README → blob B2
  3. 服务器打包 {C1, C0, T1, T0, B2, B1}
  4. 客户端写入包 → 设置引用 → 检出 C1 → 文件出现

可视化概览

refs/heads/main -> C3 -> C2 -> C1 -> C0

每个提交指向其根树；树链接到 blob；引用指向提交——形成一个单一的、内容寻址的 DAG。

关键思维模型

  • Git 是数据库，而不是文件系统。 每个文件、目录和提交都是键值存储中的不可变对象。
  • 克隆 = 图下载 + 引用绑定。 先获取对象图，再为其分配人类可读的名称（分支、标签）。
  • 工作树 = 某个树对象的视图。 切换分支仅仅是更改正在查看的树对象。
  • 索引 = 性能缓存。 它通过记录文件状态和 blob ID 加速 diff 与暂存操作。

结束语

git clone 并非仅仅复制文件。它重建了一个基于快照、哈希和关系的图形数据库。理解这一过程可以让你对 Git 实际管理代码的方式有更可预测、更透明的认识，也能体会到它为何如此高效。

Link to original article

Back to Blog

相关文章

阅读更多 »