Git全过程（二）





三、Git对象模型

Git对象

在Git系统中有四种类型的对象，所有的Git操作都是基于这四种类型的对象。
      “blob”：这种对象用来保存文件的内容。
      “tree”：可以理解成一个对象关系树，它管理一些”tree”和 “blob”对象。
      “commit”：只指向一个”tree”，它用来标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据，如时间戳、最近一次提交的作者、指向上次提交（初始commit没有这一项）。
     “tag”：给某个提交(commit) 增添一个标记。

SHA1哈希值

     上面我们介绍了Git对象，在Git系统中，每个Git对象都有一个特殊的ID来代表这个对象，这个特殊的ID就是我们所说的SHA1哈希值。

SHA1哈希值是通过SHA1算法（SHA算法家族的一种）计算出来的哈希值，对于内容不同的对象，会有不同的SHA1哈希值。如果你读过前面一篇文章，就肯定还记得我们是怎么根据commit id撤销更新的，这里的commit id就是一个SHA1哈希值。

Git对象模型实例

下面我们通过一个例子来认识一下上面的四种对象，为了更加清楚，这里将一步步展示经过一系列操作后对象的关系变化。

 第一步：新建一个仓库，添加一个”calc.py”的文件

      通过”git log -–pretty=raw”可以得到每个commit的SHA1哈希值，也可以得到这个commit对应的tree的哈希值。

所以，一个commit对象一般包含以下信息：
      代表commit的哈希值
      指向tree 对象的哈希值
      作者
      提交者
      注释

在Git对象模型的研究中，有一个很有用的命令”git cat-file”

可以通过这个命令查询特定对象的信息:
      git cat-file -t key：通过一个对象的哈希值可以通过这条命令查看对象的类型（blob、tree、commit或tag）
      git cat-file -p key：通过对象的哈希值可以查看这个对象的内容

通过以上两个命令我们可以看到在这一次的提交中产生了三个对象，同时看到了commit、tree、blob三个对象的关系如下：

一个提交(commit)由以下的部分组成:
一个 tree　对象: tree对象的SHA1签名, 代表着目录在某一时间点的内容.
父对象 (parent(s)): 提交(commit)的SHA1签名代表着当前提交前一步的项目历史. 上面的那个例子就只有一个父对象; 合并的提交(merge commits)可能会有不只一个父对象. 如果一个提交没有父对象, 那么我们就叫它“根提交"(root commit), 它就代表着项目最初的一个版本(revision). 每个项目必须有至少有一个“根提交"(root commit). 一个项目可能有多个"根提交“，虽然这并不常见(这不是好的作法).
作者 : 做了此次修改的人的名字,　还有修改日期.
提交者（committer): 实际创建提交(commit)的人的名字, 同时也带有提交日期. TA可能会和作者不是同一个人; 例如作者写一个补丁(patch)并把它用邮件发给提交者, 由他来创建提交(commit).

第二步：更新”calc.py”文件，添加sub函数

同样通过”git cat-file”我们可以看到每一个对象的类型和内容，这里就不一步一步上图了，直接给出所有的对象关系。

这里需要注意的一点，Perforce、SVN和CVS属于“增量文件系统” （Delta Storage systems），它们每次只存储提交(commit)之间的差异。而对于Git，它会把你的每次提交的文件的全部内容（snapshot）都会记录下来。

总结

Git对象模型就像是Git系统特有的文件系统，以特定的方式存储更新的内容、元数据以及版本历史信息。

四、.git目录

Git目录

下面就开始进入.git目录了，通过”ls”命令可以看到.git目录中的文件和子目录：

|-- HEAD         # 这个git项目当前处在哪个分支里
|-- config       # 项目的配置信息，git config命令会改动它
|-- description  # 项目的描述信息
|-- hooks/       # 系统默认钩子脚本目录
|-- index        # 索引文件
|-- logs/        # 各个refs的历史信息
|-- objects/     # Git本地仓库的所有对象 (commits, trees, blobs, tags)
|-- refs/        # 标识你项目里的每个分支指向了哪个提交(commit)。

Git引用

Git中的引用是个非常重要的概念，对于理解分支（branch）、HEAD指针以及reflog非常有帮助。

Git系统中的分支名、远程分支名、tag等都是指向某个commit的引用。比如master分支，origin/master远程分支，命名为V1.0.0.0的tag等都是引用，它们通过保存某个commit的SHA1哈希值指向某个commit。

重新认识HEAD

HEAD也是一个引用，一般情况下间接指向你当前所在的分支的最新的commit上。HEAD跟Git中一般的引用不同，它并不包含某个commit的SHA1哈希值，而是包含当前所在的分支，所以HEAD直接指向当前所在的分支，然后间接指向当前所在分支的最新提交。

为了更形象的解释上面的描述，我们首先查看”.git/HEAD”的内容：

ref: refs/heads/master

这就表示HEAD是一个指向master分支的引用，然后我们可以根据引用路径打开”refs/heads/master”文件，内容如下：

4ea6c317a67e73b0befcb83c36b915c1481f2efe

根据前面一片文章的介绍，我们通过这个哈希值查看对象的类型和内容，可以看到这个哈希值对应一个commit，并且通过”git log”可以发现这个commit就是master分支上最新的提交。

所有的内容都是环环相扣的，我们通过HEAD找到一个当前分支，然后通过当前分支的引用找到最新的commit，然后通过commit可以找到整个对象关系模型。

引用和分支

直到现在我们都没有开始介绍分支（branch），这里也不准备介绍分支，只是想大概展示一下引用和分支的关系。

假设我们现在除了master分支，又创建了一个release-1.0.0.1的分支，再次查看”.git/refs/heads/”目录，可以看到除了master文件之外，又多了一个release-1.0.0.1文件，查看给文件的内容也是一个哈希值。

通过”git show-ref –heads”命令就可以产看所有的头。

根据前面的讲解，这个commit就是就是release-1.0.0.1分支上最新的提交。同样，当我们把当前分支切换到release-1.0.0.1的时候，HEAD文件的内容也会相应的变成：

ref: refs/heads/release-1.0.0.1

再看reflog

我们进入”.git/logs”文件夹，可以看到这个文件夹也有一个HEAD文件和refs目录，些就是记录reflog的地方。

Git索引（index）

前面文章我们也提到过index/stage，就是更新的暂存区，下面就来看看index文件。

index（索引）示一个存放了已排序的路径的二进制文件，并且每个路径都对应一个SHA1哈希值。在Git系统中，可以通过”git ls-files –stage”来显示index文件的内容。

从命令的输出可以看到，所有的记录都对应仓库中的文件（包含全路径）。通过”git cat-file”命令查看app.py对应的哈希值，可以看到这个哈希值就是代表app.py的blob对象。

现在我们更新app.py文件，加上一个”div(16, 4)”的调用并通过”git add”添加到暂存区，这时发现index中app.py对象的哈希值已经变化了。

通过这个例子，我们也可以理解diff操作应该会有怎样的输出了：
      git diff：比较WorkSpace和stage，add之前有diff输出；add之后没有diff输出
      git diff HEAD：比较WorkSpace和repo，add之前之后都有diff输出
      git diff –cached：比较stage和repo，add之前没有diff输出；add之后有diff输出

对象的存储

前面提到所有的Git对象都会存放在”.git/objects”目录中，对象SHA1哈希值的前两位是文件夹名称，后38位作为对象文件名。

所以，我们前面提到的master上最新的commit对象的哈希值是”4ea6c317a67e73b0befcb83c36b915c1481f2efe”，那么这个对象会被存储在”.git/objects/4e/a6c317a67e73b0befcb83c36b915c1481f2efe”。进入objects目录后，我们确实找到了这个文件。

在Git系统中有两种对象存储的方式，松散对象存储和打包对象存储。

松散对象（loose object）

松散对象存储就是前面提到的，每一个对象都被写入一个单独文件中，对象SHA1哈希值的前两位是文件夹名称，后38位作为对象文件名。

打包对象（packed object）

对于松散存储，把每个文件的每个版本都作为一个单独的对象，它的效率比较低，而且浪费空间。所以就有了通过打包文件（packfile）的存储方式。

Git使用打包文件(packfile)去节省空间.。在这个格式中,，Git只会保存第二个文件中改变了的部分，然后用一个指针指向相似的那个文件。

一般Git系统会自动完成打包的工作，在已经发生过打包的Git仓库中，”.git/objects/pack”目录下会成对出现很多”pack-***.idx”和”pack-***.pack”文件。关于打包就介绍这么多了，暂时还没有去研究两个文件的内容和原理。