Git
章节 ▾ 第二版

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 会接收你提供的内容，并仅仅返回存储该内容时将使用的唯一键。-w 选项告诉命令不要仅仅返回键，而是将该对象写入数据库。最后，--stdin 选项告诉 git hash-object 从 stdin 获取要处理的内容；否则，该命令将在命令末尾期望一个文件名参数，其中包含要使用的内容。

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

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

如果你再次查看你的objects目录，你会发现它现在包含一个用于该新内容的文件。这就是 Git 最初存储内容的方式——每个内容片段都作为一个单独的文件，并使用内容及其标头的 SHA-1 校验和命名。子目录使用 SHA-1 的前两位字符命名，文件名是剩下的 38 个字符。

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

$ 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 对象类型是树，它解决了存储文件名的问题，也允许你将一组文件一起存储。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，^字符用于通配符，因此你必须将整个表达式括在引号中：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，它是之前的“版本 2”SHA-1（1f7a7a）。为了好玩，你将第一个树作为子目录添加到这个树中。你可以通过调用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 <[email protected]> 1243040974 -0700
committer Scott Chacon <[email protected]> 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 历史，你可以使用git log命令查看，如果你在最后一个提交 SHA-1 上运行它。

$ git log --stat 1a410e
commit 1a410efbd13591db07496601ebc7a059dd55cfe9
Author: Scott Chacon <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date:   Fri May 22 18:09:34 2009 -0700

    First commit

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

太棒了。你刚刚完成了构建 Git 历史的低级操作，而没有使用任何前端命令。这本质上是 Git 在你运行git add和git commit命令时所做的——它为已更改的文件存储 blob，更新索引，写出树，并写入提交对象，这些对象引用顶级树以及直接先于它们的提交。这三个主要的 Git 对象——blob、树和提交——最初作为独立的文件存储在你的.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 如何存储它的对象。你将看到如何交互式地将 blob 对象（在本例中，字符串“what is up, doc?”）存储在 Ruby 脚本语言中。

你可以使用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 中使用require命令包含 SHA1 摘要库，然后使用字符串调用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()打开文件，并将之前 zlib 压缩的内容写入文件，对生成的 文件句柄执行write()调用。

>> 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