章节 ▾ 第二版

10.2 Git 内部原理 - Git 对象

Git 对象

Git 是一个内容寻址文件系统。太好了。那是什么意思？这意味着 Git 的核心是一个简单的键值数据存储。这意味着你可以将任何类型的内容插入到 Git 仓库中，Git 将返回一个唯一的键，你以后可以使用该键检索该内容。

作为演示，让我们看看底层命令 git hash-object，它接受一些数据，将其存储在你的 .git/objects 目录（对象数据库）中，并返回唯一键，该键现在指向该数据对象。

首先，你初始化一个新的 Git 仓库，并验证 objects 目录中（不出所料）没有任何内容

$ git init test
Initialized empty Git repository in /tmp/test/.git/
$ cd test
$ find .git/objects
.git/objects
.git/objects/info
.git/objects/pack
$ find .git/objects -type f

Git 已经初始化了 objects 目录并在其中创建了 pack 和 info 子目录，但没有常规文件。现在，让我们使用 git hash-object 来创建一个新的数据对象并手动将其存储到你的新 Git 数据库中

$ echo 'test content' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4

最简单的形式下，git hash-object 将接受你提供的内容并仅仅返回将用于将其存储在 Git 数据库中的唯一键。-w 选项告诉命令不只是返回键，而是将该对象写入数据库。最后，--stdin 选项告诉 git hash-object 从标准输入获取要处理的内容；否则，该命令将期望在命令末尾有一个包含要使用的内容的 filename 参数。

上述命令的输出是一个 40 个字符的校验和哈希值。这是 SHA-1 哈希值 — 你存储的内容加上一个头部的校验和，你稍后会了解它。现在你可以看到 Git 是如何存储你的数据的

$ find .git/objects -type f
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

如果你再次检查你的 objects 目录，你会看到它现在包含了一个用于新内容的文件。这就是 Git 最初存储内容的方式 — 每个内容作为一个单独的文件，以内容的 SHA-1 校验和及其头部命名。子目录以 SHA-1 的前 2 个字符命名，文件名是剩余的 38 个字符。

一旦你的对象数据库中有了内容，你就可以使用 git cat-file 命令检查该内容。这个命令就像一把瑞士军刀，用于检查 Git 对象。向 cat-file 传递 -p 会指示该命令首先找出内容的类型，然后适当地显示它

$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
test content

现在，你可以将内容添加到 Git 并再次将其取出。你也可以对文件中的内容执行此操作。例如，你可以对文件执行一些简单的版本控制。首先，创建一个新文件并将其内容保存到数据库中

$ echo 'version 1' > test.txt
$ git hash-object -w test.txt
83baae61804e65cc73a7201a7252750c76066a30

然后，将一些新内容写入文件，并再次保存

$ echo 'version 2' > test.txt
$ git hash-object -w test.txt
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a

你的对象数据库现在包含此新文件的两个版本（以及你最初存储在那里的第一个内容）

$ find .git/objects -type f
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

此时，你可以删除本地的 test.txt 文件副本，然后使用 Git 从对象数据库中检索你保存的第一个版本

$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
$ cat test.txt
version 1

或第二个版本

$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt
$ cat test.txt
version 2

但是记住文件的每个版本的 SHA-1 键并不实用；此外，你没有在系统中存储文件名 — 只是内容。这种对象类型称为 blob。你可以让 Git 告诉你任何 Git 对象的对象类型，给定其 SHA-1 键，使用 git cat-file -t

$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
blob

树对象

我们将要研究的下一个 Git 对象类型是 tree，它解决了存储文件名的问题，并且允许你将一组文件存储在一起。Git 存储内容的方式类似于 UNIX 文件系统，但稍作简化。所有内容都以 tree 和 blob 对象的形式存储，其中 tree 对应于 UNIX 目录条目，blob 或多或少对应于索引节点或文件内容。一个 tree 对象包含一个或多个条目，每个条目都是 blob 或子树的 SHA-1 哈希值，以及其关联的模式、类型和文件名。例如，假设你有一个项目，其中最新的 tree 看起来像这样

$ git cat-file -p master^{tree}
100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
100644 blob 8f94139338f9404f26296befa88755fc2598c289      Rakefile
040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0      lib

master^{tree} 语法指定了你的 master 分支上最后一次提交所指向的树对象。注意 lib 子目录不是一个 blob，而是指向另一个树的指针

$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb
注意

根据你使用的 shell，在使用 master^{tree} 语法时可能会遇到错误。

在 Windows 上的 CMD 中，^ 字符用于转义，因此你必须将其加倍以避免此问题：git cat-file -p master^^{tree}。当使用 PowerShell 时，使用 {} 字符的参数必须用引号括起来，以避免参数解析错误：git cat-file -p 'master^{tree}'。

如果你正在使用 ZSH，^ 字符用于通配，因此你必须将整个表达式用引号括起来：git cat-file -p "master^{tree}"。

从概念上讲，Git 存储的数据看起来像这样

Simple version of the Git data model
图 173. Git 数据模型的简单版本

你可以相当容易地创建自己的树。Git 通常通过获取你的暂存区或索引的状态并从中写入一系列树对象来创建树。因此，要创建树对象，你首先必须通过暂存一些文件来设置索引。要创建一个包含单个条目的索引 — 你的 test.txt 文件的第一个版本 — 你可以使用底层命令 git update-index。你使用此命令将 test.txt 文件的早期版本人为地添加到新的暂存区。你必须传递 --add 选项，因为该文件在你的暂存区中尚不存在（你甚至还没有设置暂存区），并且传递 --cacheinfo，因为你添加的文件不在你的目录中，而是在你的数据库中。然后，你指定模式、SHA-1 和文件名

$ git update-index --add --cacheinfo 100644 \
  83baae61804e65cc73a7201a7252750c76066a30 test.txt

在这种情况下，你指定了模式 100644，这意味着它是一个普通文件。其他选项是 100755，表示它是一个可执行文件；以及 120000，指定一个符号链接。该模式取自正常的 UNIX 模式，但灵活性要差得多 — 这三种模式是 Git 中文件（blob）唯一有效的模式（尽管其他模式用于目录和子模块）。

现在，你可以使用 git write-tree 将暂存区写入一个树对象。不需要 -w 选项 — 如果该树尚不存在，调用此命令会自动从索引状态创建树对象

$ git write-tree
d8329fc1cc938780ffdd9f94e0d364e0ea74f579
$ git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579
100644 blob 83baae61804e65cc73a7201a7252750c76066a30      test.txt

你也可以使用之前看到的相同 git cat-file 命令验证这是一个树对象

$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
tree

现在你将创建一个新的树，其中包含 test.txt 的第二个版本以及一个新文件

$ echo 'new file' > new.txt
$ git update-index --cacheinfo 100644 \
  1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
$ git update-index --add new.txt

你的暂存区现在有 test.txt 的新版本以及新文件 new.txt。写出该树（将暂存区或索引的状态记录到树对象中）并查看它是什么样子

$ git write-tree
0155eb4229851634a0f03eb265b69f5a2d56f341
$ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt

请注意，此树同时具有文件条目，并且 test.txt SHA-1 是之前（1f7a7a）的“版本 2”SHA-1。为了好玩，你将第一个树作为子目录添加到这个树中。你可以通过调用 git read-tree 将树读入你的暂存区。在这种情况下，你可以使用 --prefix 选项将现有树作为子树读入你的暂存区

$ git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
$ git write-tree
3c4e9cd789d88d8d89c1073707c3585e41b0e614
$ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614
040000 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579      bak
100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt

如果你从刚刚写入的新树创建了一个工作目录，你将在工作目录的顶层获得两个文件，以及一个名为 bak 的子目录，其中包含 test.txt 文件的第一个版本。你可以将 Git 为这些结构包含的数据视为这样

The content structure of your current Git data
图 174. 当前 Git 数据的内容结构

提交对象

如果你完成了上述所有操作，你现在拥有三个树，它们代表了你想要跟踪的项目的不同快照，但之前的问题仍然存在：你必须记住所有三个 SHA-1 值才能调用这些快照。你也没有关于谁保存了快照、何时保存以及为何保存的任何信息。这是提交对象为你存储的基本信息。

要创建提交对象，你调用 commit-tree 并指定一个树 SHA-1 以及直接在其之前的任何提交对象（如果存在）。从你写入的第一个树开始

$ echo 'First commit' | git commit-tree d8329f
fdf4fc3344e67ab068f836878b6c4951e3b15f3d
注意

由于创建时间和作者数据的不同，你将获得不同的哈希值。此外，虽然原则上任何提交对象都可以根据给定的数据精确重现，但本书构建的历史细节意味着打印出的提交哈希值可能与给定的提交不对应。在本章后面，请用你自己的校验和替换提交和标签哈希值。

现在你可以用 git cat-file 查看你的新提交对象

$ git cat-file -p fdf4fc3
tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
author Scott Chacon <schacon@gmail.com> 1243040974 -0700
committer Scott Chacon <schacon@gmail.com> 1243040974 -0700

First commit

提交对象的格式很简单：它指定了该点项目快照的顶层树；父提交（如果存在）（上面描述的提交对象没有任何父提交）；作者/提交者信息（使用你的 user.name 和 user.email 配置设置以及一个时间戳）；一个空行，然后是提交消息。

接下来，你将写入另外两个提交对象，每个对象都引用紧接在其之前的提交

$ echo 'Second commit' | git commit-tree 0155eb -p fdf4fc3
cac0cab538b970a37ea1e769cbbde608743bc96d
$ echo 'Third commit'  | git commit-tree 3c4e9c -p cac0cab
1a410efbd13591db07496601ebc7a059dd55cfe9

这三个提交对象中的每一个都指向你创建的三个快照树中的一个。奇怪的是，你现在有一个真实的 Git 历史记录，如果你在最后一个提交 SHA-1 上运行 git log 命令，你可以查看它

$ git log --stat 1a410e
commit 1a410efbd13591db07496601ebc7a059dd55cfe9
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri May 22 18:15:24 2009 -0700

	Third commit

 bak/test.txt | 1 +
 1 file changed, 1 insertion(+)

commit cac0cab538b970a37ea1e769cbbde608743bc96d
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri May 22 18:14:29 2009 -0700

	Second commit

 new.txt  | 1 +
 test.txt | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri May 22 18:09:34 2009 -0700

    First commit

 test.txt | 1 +
 1 file changed, 1 insertion(+)

太棒了。你刚刚完成了低级操作，构建了 Git 历史，而没有使用任何前端命令。这本质上就是你运行 git add 和 git commit 命令时 Git 所做的事情 — 它为已更改的文件存储 blob，更新索引，写入树，并写入引用顶层树和紧接在其之前的提交的提交对象。这三个主要的 Git 对象 — blob、tree 和 commit — 最初作为单独的文件存储在你的 .git/objects 目录中。这是现在示例目录中的所有对象，并注释了它们存储的内容

$ find .git/objects -type f
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1

如果你跟踪所有内部指针，你将得到一个像这样的对象图

All the reachable objects in your Git directory
图 175. Git 目录中所有可访问的对象

对象存储

我们前面提到，你提交到 Git 对象数据库的每个对象都会存储一个头部。让我们花点时间看看 Git 是如何存储其对象的。你将看到如何使用 Ruby 脚本语言以交互方式存储一个 blob 对象 — 在本例中，字符串“what is up, doc?”。

你可以使用 irb 命令启动交互式 Ruby 模式

$ irb
>> content = "what is up, doc?"
=> "what is up, doc?"

Git 首先构造一个头部，它首先识别对象的类型 — 在这种情况下是一个 blob。在该头部的第一部分，Git 添加一个空格，后跟内容的大小（以字节为单位），并添加一个最终的空字节

>> header = "blob #{content.bytesize}\0"
=> "blob 16\u0000"

Git 将头部和原始内容连接起来，然后计算该新内容的 SHA-1 校验和。你可以在 Ruby 中通过包含 SHA1 摘要库（使用 require 命令）然后调用 Digest::SHA1.hexdigest() 并传入字符串来计算字符串的 SHA-1 值

>> store = header + content
=> "blob 16\u0000what is up, doc?"
>> require 'digest/sha1'
=> true
>> sha1 = Digest::SHA1.hexdigest(store)
=> "bd9dbf5aae1a3862dd1526723246b20206e5fc37"

让我们将其与 git hash-object 的输出进行比较。这里我们使用 echo -n 来防止在输入中添加换行符。

$ echo -n "what is up, doc?" | git hash-object --stdin
bd9dbf5aae1a3862dd1526723246b20206e5fc37

Git 使用 zlib 压缩新内容，你可以在 Ruby 中使用 zlib 库进行压缩。首先，你需要引用该库，然后对内容运行 Zlib::Deflate.deflate()

>> require 'zlib'
=> true
>> zlib_content = Zlib::Deflate.deflate(store)
=> "x\x9CK\xCA\xC9OR04c(\xCFH,Q\xC8,V(-\xD0QH\xC9O\xB6\a\x00_\x1C\a\x9D"

最后，你将 zlib 压缩的内容写入磁盘上的一个对象。你将确定要写入的对象的路径（SHA-1 值的前两个字符是子目录名，后 38 个字符是该目录中的文件名）。在 Ruby 中，你可以使用 FileUtils.mkdir_p() 函数创建子目录（如果它不存在）。然后，使用 File.open() 打开文件，并使用对生成的 File Handle 的 write() 调用将先前 zlib 压缩的内容写入文件

>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
>> require 'fileutils'
=> true
>> FileUtils.mkdir_p(File.dirname(path))
=> ".git/objects/bd"
>> File.open(path, 'w') { |f| f.write zlib_content }
=> 32

让我们使用 git cat-file 检查对象的内容

---
$ git cat-file -p bd9dbf5aae1a3862dd1526723246b20206e5fc37
what is up, doc?
---

就是这样——你创建了一个有效的 Git blob 对象。

所有 Git 对象的存储方式都相同，只是类型不同——而不是字符串 blob，头部将以 commit 或 tree 开头。此外，虽然 blob 内容可以是几乎任何内容，但 commit 和 tree 内容的格式非常特定。