本文共 11242 字,大约阅读时间需要 37 分钟。
在本文中我将使用一些底层的命令来展示 Git 内部是怎么工作的。你不需要记住这些命令,因为在常规的工作流中几乎不会使用这些命令,但是这些命令在解释 Git 内部架构时不可或缺。
本文比较长,我相信你会按照以下两种方式阅读:
通过练习你可以增强在这里获得的信息。
当你在一个文件夹中执行 git init
命令时,Git 会创建 .git
目录。所以我们打开一个终端,创建一个新的目录并在这里初始化一个空的 git 仓库:
$ mkdir git-playground && cd git-playground$ git initInitialized empty Git repository in path/to/git-playground/.git/$ ls .gitHEAD config description hooks info objects refs
这是 Git 存储所有 commit 和其他用于操作这些 commit 相关信息的地方。当你克隆一个仓库的时候就是复制这个目录到你的文件夹,为仓库里的每一个分支创建一个远程跟踪分支,并根据 HEAD 文件检出一个初始的分支。我们将在稍后讨论在 Git 架构中 HEAD 文件的用途,但是这里需要记住的就是克隆一个仓库本质上就是仅仅从别的地方复制一份 .git
目录。
Git 是一个简单的 key-value 数据仓库。你可以将数据存储到仓库中并获得一个键值,通过这个键值你可以访问存储的数据。将数据存储到数据库的命令是 hash-object
,这个命令会返回一个40个字符的哈希校验和,这个校验和会被用作键值。这个命令会在 git 仓库中创建一个称为 blob
的对象。我们向数据库中写入一个简单的字符串 f1 content
:
$ F1CONTENT_BLOB_HASH=$( \ echo 'f1 content' | git hash-object -w --stdin )$ echo $F1CONTENT_BLOB_HASHa1deaae8f9ac984a5bfd0e8eecfbafaf4a90a3d0
如果你对 shell 不熟悉,上面这一段代码的主要命令是:
echo 'f1 content' | git hash-object -w --stdin
echo
命令输出 f1 content
字符串,通过管道操作符 |
我们将输出重定位到 git hash-object
命令。hash-object
的参数 -w
表示要存储这个对象;否则这个命令只是简单的告诉你键值是什么。 --stdin
告诉命令从 stdin 读取内容;如果不指定这一点, hash-object
希望最后输入一个文件路径。前面已经说到 git hash-object
命令会返回一个哈希值,我将这个值存储到 F1CONTENT_BLOB_HASH
变量中。我们也可以将主命令和变量赋值像这样分开:
$ echo 'f1 content' | git hash-object -w --stdina1deaae8f9ac984a5bfd0e8eecfbafaf4a90a3d0$ F1CONTENT_BLOB_HASH=a1deaae8f9ac984a5bfd0e8eecfbafaf4a90a3d0
但是为了方便,我将在后面的代码中使用简短的版本为变量赋值。这些变量会在需要哈希字符串的地方使用,它和 $
符号拼接起来作为一个变量读取存储的数据。
通过键值读取数据可以使用 带有 -p
选项的 cat-file
命令。这个命令需要接收带读取数据的哈希值:
如我前面所说, .git
是一个文件夹,并且所有存储的值/对象都放在这个文件夹中。所以我们可以浏览一下 .git/objects
文件夹,你会看到 Git 创建了一个名称为 a1
的文件夹,这是哈希值的前两个字母:
$ ls .git/objects/ -l**a1/** info/ pack/
这就是 Git 存储对象的方式–每个 blob 一个文件夹。然而,Git 也可以将多个 blob 合并成一个文件生成一个 pack 文件,这些 pack 文件就存储在你前面看到的 pack
目录。Git 将这些 pack 对象相关的信息都存储到 info
目录。Git 基于 blob 的内容为每一个 blob 生成哈希值,所以存储在 Git 中的对象是不可修改的,因为修改内容就会改变哈希值。
我们往仓库中写入另外一个字符串 f2 content
:
$ F2CONTENT_BLOB_HASH=$( \ **echo 'f2 content' | git hash-object -w --stdin )**
如你所预期的那样,你会看到 .git/objects/
目录下现在有两条记录 9b/
和 a1/
:
$ ls .git/objects/ -l**9b/** **a1/ **info/ pack/
现在我们的仓库中有两个blob:
F1CONTENT_BLOB_HASH -> ‘f1 content’F2CONTENT_BLOB_HASH -> ‘f2 content'
我们需要一种方式来将他们组织到一起,并且将每一个 blob 和一个文件名关联起来。这就是 tree 的作用。我们可以按照下面的语法通过 git mktree
为从而每一个 blob/文件 关联创建一个树:
[file-mode object-type object-hash file-name]
关于文件的 file mode 可以参考提供的解释。我们将使用 100644
模式,这一模式下 blob 就是一个常规文件每一个用户都可以读写。当检出文件到工作目录时,Git 会根据 tree 实体将相应的文件/目录设置成这个模式。
所以,这样就可以将两个 blob 和两个文件建立关联:
$ INITIAL_TREE_HASH=$( \ printf '%s %s %s\t%s\n' \ 100644 blob $F1CONTENT_BLOB_HASH f1.txt \ 100644 blob $F2CONTENT_BLOB_HASH f2.txt | git mktree )
和 hash-object
一样,mktree
命令也会返回创建好的树对象的哈希值:
$ echo $INITIAL_TREE_HASHe05d9daa03229f7a7f6456d3d091d0e685e6a9db
所以,现在我们的仓库中有这样一个树:
运行这个命令之后,git 在仓库中创建了第三个 tree
类型的对象。我们一起来看看:
$ ls .git/objects -le0 <--- initial tree object (INITIAL_TREE_HASH)9b <--- 'f1 content' blob (F2CONTENT_BLOB_HASH)a1 <--- 'f2 content' blob (F2CONTENT_BLOB_HASH)
当使用 mktree
命令的时候,我们也可以指定另外一个树对象(而不是一个 blob)作为参数。新创建的树会和目录而不是一个常规文件关联。例如,下面的命令会根据一个 subtree 创建一个和 nested-folder
目录关联的树:
printf ‘%s %s %s\t%s\n’ 040000 tree e05d9da nested-folder | git mktree
文件模式 040000
表明是一个目录,并且我们使用的类型 tree
而不是 blob
。这就是 git 在项目结构中存储嵌套目录的方式。
每一个使用 GIT 工作的人都应该很熟悉 index 或者 staging 区这两个概念,并且可能看到过这张图片:
在右侧你可以看到 git repository,它用于存储 git 对象:blobs,trees,commits 和 tags。我们已经使用 hash-object
和 mktee
命令直接向仓库中添加了两个 blob 和一个树对象到仓库中。左侧的工作目录是你本地的文件系统(目录),也就是你检出所有项目文件的地方。中间这个区域我们称为 index 文件或者简称 index。它是一个二进制文件(通常存储在 .git/index
),类似于树对象的结构。它持有一个排序好的文件路径列表,每一个文件路径都有权限以及 blob/tree 对象的 SHA1 值。
在这个地方,git 在作如下操作之前准备一个树:
现在我们的仓库中已经有一个在上一章节创建的树。我们现在可以使用 read-tree
命令将这个树从仓库中读取到 index 文件:
$ git read-tree $INITIAL_TREE_HASH
所以现在我们期望 index 文件中有两个文件。我们可以使用 git ls-files -s
命令来检查当前 index 文件的结构:
$ git ls-files -s100644 a1deaae8f9ac984a5bfd0e8eecfbafaf4a90a3d0 0 f1.txt100644 9b96e21cb748285ebec53daec4afb2bdcb9a360a 0 f2.txt
由于我们还没有对 index 文件做任何修改,它和我们用于生成index文件的树完全一致。一旦我们在 index 文件中有了正确的结构,我们就可以通过带有 -a
选项的 checkout-index
命令将它检出到工作目录:
$ git checkout-index -a$ lsf1.txt f2.txt$ cat f1.txtf1 content$ cat f2.txtf2 content
对的!我们已经将没使用任何 commit 就添加到 git 仓库中的内容检出了。是不是很酷?
但是 index 文件并非总是停留在初始树的状态。你可能知道它可以通过这些命令改变,git add [file path]
和 git rm --cached [file path]
处理单个文件,git add .
和 git reset
处理一批已修改/已删除的文件。我们将这个知识用于实践,在仓库中创建一个新的树,这个树包含一个和文本文件 f3.txt
关联的 blob 文件。文件的内容就是字符串 f3 content
。但是和前一节手动创建树不一样,我们将使用index文件来创建。
现在我们的 index 文件结构如下,
这就是我们应用修改的基准。你对 index 文件所做的所有修改在将树写入仓库之前都是暂时的。然而你添加的对象是立刻写入到仓库的。如果你放弃当前对树的修改,这些对象稍后会被垃圾回收搜集并删除。 这意味着如果你不小心丢弃了对某一个文件的修改,在 git 运行 GC 之前是可以恢复的。垃圾回收通常发生在有太多的未引用对象时才发生。
我们来删除工作目录中的两个文件:
$ rm f1.txt f2.txt
如果我们运行git status
我们会看到以下信息:
$ git statusOn branch masterInitial commitChanges to be committed: (use "git rm --cached..." to unstage) new file: f1.txt new file: f2.txtChanges not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) deleted: f1.txt deleted: f2.txt
信息有点多。有两个文件被删除、两个新文件同时还是 “Initial commit”。我们来看看为什么。当你运行 git status
时,git做了两个比较:
所以在这里我们看到 git 将两个已删除的文件报告为 “Changes not staged for commit”,我们已经知道这个信息是怎产生的–它将当前的工作目录和 index 文件比较发现工作目录丢失两个文件(因为我们刚才删除了)。
我们同时还看在 “Changes to be committed” 下面 git 报告了了两个新文件。这是因为到目前为止我们的仓库中还没有任何提交,所以这个 HEAD
文件(我们稍后做详细的解释)指向一个所谓的“空树”对象(没有任何文件)。所以 Git 以为我们刚刚创建了一个新的仓库,所以为什么它显示 “Initial commit”,并将 index 文件中的所有文件都当做新文件。
现在如果我们执行 git add .
它将修改 index 文件(删除了两个文件),然后再次执行 git status
就会显示没有任何修改,因为现在我们的工作目录和 index 文件中都没有文件:
$ git add .$ git statusOn branch masterInitial commitnothing to commit (create/copy files and use "git add" to track)
我们继续通过创建新文件 f3.txt
来创建一个新的树。
$ echo ‘f3 content’ > f3.txt$ git add f3.txt
如果现在运行 git status
:
$ git statusOn branch masterInitial commitChanges to be committed: (use "git rm --cached..." to unstage) new file: f3.txt
我们发现检查到了一个新文件。同样,这个修改是报告在 “Changes to be committed” 下,所以现在 Git 是将 index 文件和 “空树” 作比较。所以认为 index 文件中已经有了新的文件 blob。我们来确认一下:
$ git ls-files -s100644 5927d85c2470d49403f56ce27afd8f74b1a42589 0 f3.txt# Save the hash of the f3.txt file blob$ F3CONTENT_BLOB_HASH=5927d85c2470d49403f56ce27afd8f74b1a42589
好了,index 的结构是正确的,我们现在可以通过这个 index 在仓库中创建一个树。我们通过 write-tree
命令来完成:
$ LATEST_TREE_HASH=$( git write-tree )
很棒。我们刚才通过 index 创建了一个树。并且将新的树的哈希值存到了 LATEST_TREE_HASH
变量。我们已经通过手动将 f3 content
blob 写入到仓库并且通过 mktree
来创建了一个树,但是使用 index 文件更方便。
有趣的是如果你现在运行 git status
你会发现git 仍然认为存在一个新文件 f3.txt
:
$ git statusOn branch masterInitial commitChanges to be committed: (use "git rm --cached..." to unstage) new file: f3.txt
那是因为尽管我们已经创建了一个树并将它存入了仓库,但是我们还没有更新用于比较的 HEAD 文件。
所以加上我们新创建的树,仓库中有以下对象:
在这一节中将变得更有趣。在我们日常的 Git 使用中,我们基本不会使用树或者 blob。我们和 commit 对象交互。所以 git 中的 commit 是什么?实际上,简单说它就是对树对象的封装:
现在我们的仓库中有两个树–initial tree
和 latest tree
。我们通过 commit-tree
命令将第一个树封装成一个 commit(将树的哈希值传递给它):
INITIAL_COMMIT_HASH=$( \ echo 'initial commit' | git commit-tree $INITIAL_TREE_HASH )
在运行上面的命令之后:
现在我么可以将这个commit检出到工作目录:
$ git checkout $INITIAL_COMMIT_HASHA f3.txtHEAD is now at a27a75a... initial commit
我们现在可以看到 f1.txt f2.txt 处于工作目录中:
$ lsf1.txt f2.txt$ cat f1.txtf1 content$ cat f2.txtf2 content
当你运行 git checkout [commit-hash]
时,git 做了如下动作:
这些都是我们在上一节手动执行的操作。
所以现在我们知道了一个 commit 就是对一个树的封装。我也讲到一个 commit 可以有一个父 commit。我们最初有两个树并在上一节将其中一个封装成了一个commit,所以现在我们还有一个孤立的树。我们来将它封装成另外一个 commit 并指定其父 commit 为 initial commit。我们会使用和前一节相同的操作 commit-tree
,不过需要通过-p
选项来指定父 commit。
现在应该是这样:
所以如果你现在将最后一次 commit 的哈希值传递给 git log
你会看到提交历史中有两条提交记录:
$ git log --pretty=oneline $LATEST_COMMIT_HASH[some hash] latest commit[some hash] initial commit
并且你可以在他们之间切换。这里是 initial commit:
$ git checkout $INITIAL_COMMIT_HASH$ lsf1.txt f2.txt
latest commit
$ git checkout $LATEST_COMMIT_HASH$ lsf3.txt
HEAD 是存放在 .git/HEAD
的文本文件,它是对当前已检出 commit 的引用。由于我们在前面一节中通过 $LATEST_COMMIT_HASH
检出了最后的commit,此时 HEAD
文件包含的全部内容:
$ cat .git/HEAD88d3b9901d62fc1de9219f388e700d98bdb97ba9$ [ $LATEST_COMMIT_HASH == "88d3b9901d62..." ]; echo 'equal'equal
然而,通常 HEAD 文件是通过分支引用来引用当前检出的 commit。当它直接引用一个 commit 的时候它是处于 detached state
(分离状态)。但是即使当 HEAD 像这样通过分支持有一个引用:
ref: refs/heads/master
它仍然是引用一个 commit 的哈希值。
你现在知道了在执行 git status
命令时, Git 使用通过HEAD
引用的 commit 来产生一系列 index 文件和当前检出的树/commit 之间的修改。HEAD
的另外一个用途就是决定下一个 commit 的父 commit。
有趣的是,HEAD 文件对大多数操作都是如此重要以至于如果你手动清除其内容,Git 将认为不是一个 git 仓库并报错:
fatal: Not a git repository (or any of the parent directories): .git
所以现在我们的仓库中有两条 commit,形成了如下提交历史:
$ git log --pretty=oneline $LATEST_COMMIT_HASH[some hash] latest commit[some hash] initial commit
我们在已有的历史中引入一个分叉。我们将检出最初的 commit 并修改 f1.txt
文件内容。然后使用你已经习惯的 git commit
命令创建一条新的 commit:
$ git checkout $INITIAL_COMMIT_HASH$ echo 'I am modified f1 content' > f1.txt$ git add f1.txt$ git commit -m "forked commit"1 file changed, 1 insertion(+), 1 deletion(-)
以上的代码片段:
"initial commit"
将 f1.txt
和 f2.txt
添加到工作目录f1.txt
的内容也替换为字符串 I am modified f1 content
git add
更新index 文件 git commit
命令内部做了以下操作:initial commit
作为新创建 commit 的父commit,因为当前 HEAD
文件中的 commit 就是 initial commit
。我们同样需要将新的 commit 的哈希值存储到变量中。由于 Git 根据当前的 commit 文件更新 HEAD,我们可以这样读取这个值:
FORKED_COMMIT_HASH=$( cat .git/HEAD )
所以现在我们的 git 仓库中是这样一些对象的:
由此生成以下提交历史:
由于分叉的出现我们现在有两条工作线。这意味着我们需要引入两条分支独立跟踪每一条工作线。我们创建 master
分支来跟踪从 latest commit
以来的直线历史,创建 forked
分支来跟踪自 forked commit
以来的历史。
一个分支就是一个文本文件,它包含了一个commit的哈希值。它是 git引用的一部分–引用一个 commit 的一组对象。另外一个引用类型是轻量的 tag。Git 将所有的引用存储到 .git/refs
目录,将所有分支存储在 .git/refs/heads
目录。由于分支就是一个文本文件,我们可以使用 commit 的哈希值来创建一个分支。
所以下面的分支将指向主分支的 “latest commit”。
$ echo $LATEST_COMMIT_HASH > .git/refs/heads/master
这一个分支将指向 “forked” 分支的 “forked commit”:
$ echo $FORKED_COMMIT_HASH > .git/refs/heads/forked
所以最终我们回到了你常常使用的工作流—我们现在可以在分支之间切换:
$ git checkout masterSwitched to branch 'master'$ git log --pretty=oneline[some hash] latest commit[some hash] first commit$ ls -lf3.txt
一起来看看另外一个 forked
分支:
$ git checkout forkedSwitched to branch 'forked'$ git log --pretty=onelinef30305a8a23312f70ba985c8c644fcdca19dab95 forked commitf30305a8a23312f70ba985c8c644fcdca19dab95 initial commit$ git lsf1.txt f2.txt$ cat f1.txtI am modified f1 content
你兴许已经知道除了使用分支(一条工作线的)还可以使用 tag 来跟踪单独的 commit。Tag 通常用于标记重要的开发节点如版本发布。现在我们的仓库中有3个 commit。我们可以使用 tag 来给它们命名。和分支一样,一个 tag 就是一个文本文件,它包含了一个 commit 的哈希值,同样也是引用组的一部分。
你已经知道 git 将所有的引用都存储在 .git/refs
目录,所以tag都存储在 .git/refs/tags
子目录。由于它就是一个文本文件,我们可以创建一个文件并将 commit 的哈希值写入其中。
所以这个 tag 会指向 latest commit:
$ echo $FORKED_COMMIT_HASH > .git/refs/tags/forked
这个 tag 会指向 initial commit:
$ echo $INITIAL_COMMIT_HASH > .git/refs/tags/initial
一旦完成了这一步我们就可以使用 tag 在 commit 之间切换。这样就可以切换到 initial commit:
$ git checkout tags/initialHEAD is now at 285aec7... second commit$ cat f1.txtf1 content
这样就切换到 forked commit:
$ git checkout tags/forked$ cat f1.txtI am modified f1 content
此外还有 “annotated-tag”,它和我们现在使用的轻量级 tag有所不同。它是一个对象,可以像commit一样包含信息,并且是其他对象一起存放在仓库中。
转载地址:http://gnmcn.baihongyu.com/