深入理解 Git

深入理解 Git

Git 使我们日常使用的开发工具,用于代码的版本管理,但是我们常用的各种命令 git add, git commit, git push, git pull 等等究竟是啥样子,带着好奇心,趁着空重新读了下 Git 的官方文档。发现了一些除了刚刚提到的高级命令以外的低级命令,以及 Git 究竟是如何运转的。(当然不是源码解读)

基本概念

git 对于文件的存储位置进行了3层分割,用于不同状态下的文件。我们可以理解为3个箱子。

  • Work Directory
  • Index/Stage
  • Git Directory

Work Directory(俗称工作区)

工作区就是我们文件正常编辑的地方,我们在这进行代码的编写。当我们完成之后,我们会发现我的的 cli 会提示我们这些文件被修改,从而方便我们区分哪些文件被修改了,哪些没有被修改。

Index/Stage(暂存区)

暂存区就是我们在执行了 git add 之后,文件存放的地方,说明这些文件准备进行提交了。之所以有这么个地方,就是能够将需要提交的内容进行一次性提交,从而避免了每次提交都存在歧义的情况。同时也方便我们对将要提交的地方进行调整。

Git Directory

Git 的区域,用于将历史记录进行统一的进行管理。方便后续迭代的时候进行一定的调整。git 中使用文件的形式进行管理。

前面所说可能比较抽象,用一个简单的话来说,当我们大脑中有一个好的 idea 的时候,我们的大脑就是一个 work directory,这个时候为了避免忘记,或者它丢失,我们需要将他用笔写下来,这个时候纸就是 Index/Stage。同时我们会进行不断的思考,那么就是不断的修改 work directory 的内容,并不断 add 到 Index/Stage 当中。当这个 idea 整理清楚的时候,我们需要将这张纸整理起来,就像是放到档案室,这个时候档案室就是我们的 Git Directory

Git 基本对象

说完这些,就可以进入我们的正题了。

Git 实际上有自己对于对象的定义。 Git 当中存在 3种对象,blobtreecommit。而所有对象都有自己的身份标记 —— SHA-1码。(对于 SHA-1 的解释可以参见维基百科)

blob

blob 就是我们所说的简单文件,在谷歌中的翻译 blob 指的是大的二进制文件。在 git 中你可以认为他就是文件对象。

tree

既然有了文件对象,那么需要对于文件对象进行层级排列。这个时候就需要引入 tree 的概念了。Git 模仿了 Unix 的文件管理体系,不过他没有系统的那么沉重,相对而言更加轻量级,仅仅包含了里面有哪些文件。

commit

当文件结构已经确定了,剩下的就是将这些内容进行提交了。每次当我们将 tree 提交的时候,就创建了一个 commit,而有 SHA-1 的 commit 便决定了 Git 的整个体系,能够通过 SHA-1 进行追踪。

在清楚了上面的几个关键点之后,就可以进入我们的正题了。从我们创建 git 到提交完成整个工程,具体发生了些什么。

深入理解 Git

创建 git

当我们完成了 git init 之后,我们创建了一个包含了 .git 的文件目录

➜  test git:(master) la
total 0
drwxr-xr-x  10 zkhcreator  staff   320B Jan 31 18:40 .git
复制代码

这个时候我们会发现 .git 文件下的结构如下:(附带功能描述)

.git
├── HEAD    (用于管理 HEAD 所在的位置)
├── branches    (有哪些分支)
├── config  (配置文件)
├── description (对于这个工程的描述文件)
├── hooks   (本地的 git 的所有钩子的配置)
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── info
│   └── exclude (用于在 git 层面告知 git 哪些文件不需要进行版本控制)
├── objects (所有 git 对象)
│   ├── info    (git 对象的信息,对象以及他的 SHA-1 存储的地方)
│   └── pack    (git 执行 gc 操作打包后的存储地)
└── refs    (所有引用(references)的地方)
    ├── heads   (所有分支头所在的位置)
    └── tags    (所有标签所在的位置)
复制代码

上图的文件树结构构成了一个简单的 git

创建 blob

按照往常的思路,我们需要创建文件并执行 git add filename 但是这里我们不用这些高级命令,转而使用低级命令。

首先我们创建一个文件 echo 'test1' | git hash-object -w --stdin 这样就创建完成了一个文件,其中 -w 直接将数据写入数据库(准确的说是文件当中,因为 git 没有数据库这个概念,都是以文件进行存储的)当中,--stdin 表示使用标准输入输出数据流格式进行读取。

此时我们会发现他返回了一条 SHA-1: a5bce3fd2565d8f458555a0c6f42d0504a848bd5,同时再次打印我们 .git 中的文件路径,我们会发现他的 objects 路径下多了 a5/bce3fd2565d8f458555a0c6f42d0504a848bd5 这样的一个文件,这个和生成的 SHA-1 有一些微妙的联系,实际上 git 取了 git 的前两位作为一级目录,并将后面的位数作为文件名。

如果我们尝试去打开这个文件,我们会发现他是一堆乱码,因为 git 已经帮我转我一次了,如果需要读取里面的内容,我们需要使用 git cat-file -p a5bce3fd2565d8f458555a0c6f42d0504a848bd5 去进行展示,很明显,他就会输出我们刚刚通过数据流输入输出的 test1。上面命令中的 git cat-file -p 就是用来打印 SHA-1 对象的实际内容。

有人可能会说,我们 git 不都是添加文件的么?你这样直接写数据库算什么?

那我们来新建一个文件来重复以上操作。我们执行以下命令

$ echo "version 1" > just_for_test.txt
$ git hash-object -w just_for_test.txt
83baae61804e65cc73a7201a7252750c76066a30
复制代码

这个时候我们发现又多了一个文件 .git/objects/83/baae61804e65cc73a7201a7252750c76066a30,然后我们再执行一次写入操作,尝试去修改里面的内容

echo "version 2" > just_for_test.txt
git hash-object -w just_for_test.txt
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
复制代码

这个时候我们会发现,结构路径除了我们刚刚生成的 83baae61(为了方便理解,取前几位),还有一条新的 .git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a。很明显,文件更新的情况,已经被写入到 git 的文件中。

但是我们执行 git status 会发现,文件还没有提交,说明 git 在添加到 commit 前,会将文件进行缓存。(不过什么时候进行存储数据库的,可能需要看下源码)

既然已经有了 sha-1 并且我们已经将文件存储到数据库,这个时候我们做数据恢复操作就很简单了。只需要执行 git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt 即可将前面的 version 1 恢复到文件目录当中。

这个时候如果我们重新执行 git has-object -w just_for_test.txt 我们会发现目录结构没有发生改变,因为 git 对于文件进行存储是基于文件内部的内容的,和其他的东西并无关系。

前面提到,git 当中总共有3种类型,但是 SHA-1 是通的,所以,有时候我们需要确认对应的 SHA-1 是什么类型,我们就可以使用 git cat-file -t SHA-1 进行打印,很明显,这个文件是 blob 对象。

创建 tree

如果单纯的文件,肯定是不能构成树目录的,就像我们脑子中的点子,顺序很乱,只有当我们写下来的时候,才能将它的顺序理清楚。所以只有当需要提交到 stash 才能确定谁再哪。

那么我们需要首先给文件提供一个暂存,故需要执行 git update-index --add --cacheinfo 100644 83baae61804e65cc73a7201a7252750c76066a30 just_for_test.txt 将在数据库当中指定的文件进行存储到暂存区。--add 标识将工作区域的文件注册到暂存区当中,但是如果已经添加,则不会重复添加。--cacheinfo 标识需要添加的数据的详细信息,比如说添加指定文件,以及他们的权限。**其中的文件名是放到缓存中的文件名,一般我们通过 add 进去的 work directory 和 stage 是一致的,但是可以手动指定不同,SHA-1 用来确定文件的内容具体是啥。**此时我们执行 git status 会发现,文件已经被添加到暂存区了。

然后通过 git write-tree 将当前暂存区域的对象写到树对象当中。这个时候我们会发现它又给了我们一个 SHA-1:ffb66e4709bf8e9c0b101e63c6dbea3780293ff3 这个是生成的树对象的标识符,我们可以通过 git cat-file -t SHA-1 来获得它的类型就是我们想要的 tree。 当然通过搜索 $ find .git/objects/ff 也能在 objects 中很容易找到我们需要的文件。

那么树对象能进行嵌套么?答案当然是肯定的。

我们可以通过 git read-tree --prefix=bak ffb66e4709bf8e9c0b101e63c6dbea3780293ff3 来将原有的 tree 进行备份到当前的 tree 下面,由于老的 tree 是 object 对象,所以当你读取出来之后,你在 git status 下你会发现他被写入暂存区了,但是在 work directory 当中是需要删除的,也就是这个文件本身是不存在的,这都是因为无中生有,或者说强制读取对象的造成的。

创建 commit

既然完成了 stage 的写入,最后一步就是需要将当前的 tree 进行提交,并创建提交对象。这时候只需要执行 echo "first commit" | git commit-tree f9b1ec32e2c3b591a72aeec583da3dced8eaa2aa 这个时候,我们通过 git log 会发现,我们已经提交了 commit。但是 git status 还是有文件没有更新。这个原因也很简单,就是因为我们没有创建分支,这就导致 commit 不知道该提交到哪里。 只需要 git branch new_branch_name $(echo "commit message" | git commit-tree f9b1ec32e2c3b591a72aeec583da3dced8eaa2aa) 即可。

最后

当我们提交完上面的操作之后,也就是完成了我们最基本的常用命令的底层的操作。这个时候我们重新打印下我们的 .git 文件。会发现里面多了好多东西,除了我们自己的 objects 还有很多刚刚注释里面提到的,但是文章当中没有提到的内容。 比如说:

  • COMMIT_EDITMSG:最近一次 commit 的内容
  • HEAD:当前的头的位置,ref: refs/heads/master 即引用的位置为 refs/heads/master 文件夹中的内容。
  • INDEX:放置过 index 之后,即执行 git update-index 之后 index 的内容,编码过后的文件,不能容易的看懂。
  • logs/HEAD:HEAD 切换的日志文件。
  • logs/refs/heads/master: master 的 git 修改日志情况。左边为 0,右边有值寿命这个是新添加的。相反右边为 0说明文件是移除的。同时数字前4位标识所有内容长度的十六进制数,主要方便上传下载的智能协议的同步操作。具体内容可见 Git 传输协议
0000000000000000000000000000000000000000 d6f0ab93a960f0aa1127ce4a3cf2fb00c5cee78f zkhCreator  1548937962 +0800	commit (initial): test
d6f0ab93a960f0aa1127ce4a3cf2fb00c5cee78f b6542b871b52bdf66481d03127620e1d7b7d37c9 zkhCreator  1548938032 +0800	commit: test2
复制代码
  • refs/heads/master:当前这个 master 对应的提交对象的 SHA-1 值。
  • refs/tags:对应 tag 的指向的提交对象的 SHA-1 值存储的地方。

最后的最后

当然其中还存在 objects/infoobjects/pack 这两个。你可以尝试在工程中执行 git gc 来对当前内容进行整理。你会发现文件当中的 objects/ 目录下干净了很多,仅仅留下了 objects/info/packsobjects/pack 。这个时候实际上 git 将你的文件进行了打包操作,从而减少了整个工程的体积。路径中的 pack-SHA1.idx 就是这个包的索引,里面包含了打包之后的文件信息(主要用于上传下载的过程中的不常用的文件索引,可以通过 git verify-pack -v .git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx 进行查看文件目录),pack-SHA1.pack 则是压缩的 git 对象的集合。对于细节想了解的同学可以查看官网的Git 内部文件。

你可能感兴趣的:(深入理解 Git)