章节 ▾ 第二版

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 的前两个字符命名，文件名则是剩余的 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 cat-file -t 命令，给定其 SHA-1 键，让 Git 告诉你 Git 中任何对象的类型

$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
blob

树对象

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

$ 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，^ 字符用于 globbing（文件模式匹配），因此你必须将整个表达式用引号括起来：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 校验和。你可以通过使用 require 命令包含 SHA1 digest 库，然后用字符串调用 Digest::SHA1.hexdigest() 来计算 Ruby 中字符串的 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() 打开文件，并使用对所得文件句柄的 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 对象的存储方式都相同，只是类型不同——头部将以 commit 或 tree 开头，而不是字符串 blob。此外，尽管 blob 内容几乎可以是任何东西，但 commit 和 tree 内容都有非常特定的格式。

scroll-to-top