现在我们已经基本熟悉了GIT的基本操作了,接下来该执行研究一下GIT的几个比较重要的组件,GIT有四个常用的组件
- Tag
- Commit
- Tree
- BLOB
最重要的是后面的三个,Tag组件在介绍了标签之后再来说明。后三个组件管理着GIT的所有版本文件。
如图所示:Commit组件包含了Tree,Tree组件中又有Blob组件,那么组件究竟有什么意义,又是以什么的方式被应用了,通过具体的实例来说明,首先,初始化一个目录为GIT的Repository,之后查看一下.git目录
所有的组件都存储在objects
文件夹中,初始化之后只会有info和pack两个文件夹,接着我们使用echo a > a.txt
来创建一个文件,并且使用git add .
将其提交给GIT的Stage,此时再看一下objects
文件夹
此时多了一个f5的文件夹,里面有一个文件名很长的文件,这个文件夹就是一个blob
组件,当每次把文件设置为Staged
状态的时候,就会在objects中创建一个Blob组件,这里需要强调一下,GIT中每个组件都是以hash的二进制方式来存储,这个组件的名称就是文件夹名称+文件夹中的文件的名称,这个hash码是唯一的,我们刚才所创建的组件的hash码就是f5eea678d87a8664e4c76e12d3ef5c4ff775ad58
,这也是组件的唯一标示。
blob
组件并不会对文件信息进行存储,而是对文件的内容进行记录的(note:不同的文件a.txt,b.txt,但是文件的内容一致的化,那么blob对象就是一致; 同一个文件a.txt,因为内容的修改不一样,从而会生成新的blob对象),我们执行下一个操作,echo b > a.txt
添加一个文件,我们把a.txt中的内容替换成b(原来是a),此时文件的状态变成Modified
状态,再次通过git add .
提交文件到Stage。
此时再观察objects
目录
多了一个2f的目录,虽然我们的文件没有发生变化,但是内容发生了变化,此时git会再次创建一个blob组件存储到objects文件夹中,我们再次执行下一个操作echo b > b.txt
该命令会创建一个新的文件b.txt,但是文件的内容和a.txt一样,然后使用git add .
添加到Stage中
目前a.txt和b.txt都是属于Staged状态,此时再去objects
文件夹中看一下。
并没有增加任何blob组件,因为b.txt的内容其实和a.txt一样,所以git发现这个blob已经存在了,就不会再增加新的组件。
再次强调一下blob组件是在代码提交到Stage区域的时候生成的,而且是以内容来生成一个字节码文件
我们可以通过命令git hash-object 文件名
查询文件的hash码
E:\teacher\git_teacher\05>git hash-object a.txt
2fea07c1b36b55a95b543c7bd0decbd6798bf9b9
E:\teacher\git_teacher\05>git hash-object b.txt
2fea07c1b36b55a95b543c7bd0decbd6798bf9b9
我们的a.txt和b.txt是完全一样的名称,这个hash码就是我们的blob组件的名称,再去对应一下文件夹和文件夹中的文件名。
了解了blob组件只会,我们执行下面一个操作,我们把Staged中的内容提交到工厂中,提交之前请观察objects
文件夹,执行git commit -m "init"
之后。
我们会发现多了两个文件夹d6和f5,这两个文件夹究竟是什么呢(note:多的2个,一个是tree对象,一个是commit对象)?我们通过git log
看一下
我们看到了一个commit d6297311385982c2b1552c265df08e1d07d27399
,这就是我们即将要探讨的commit组件了,而后面这串hash就是这个组件的id,在git中所有的组件都是以hash来存储的,刚才讲的blob也是一样,而且都是以hash的前两位为文件夹,剩余的位数作为文件名。
commit组件在每次提交之后都会生成,当我们进行commit之后,首先会创建一个commit组件,之后把所有的文件信息创建一个tree组件,然后把Stage Area中的blob组件封装在tree中完成一次提交,我们可以通过如下命令查询commit组件
git cat-file -p d6297
cat-file可以获取这个组件的信息d6297就是组件id的缩写(只要写前面的5位git会自动找到这个组件)
我们会发现commit组件下有一个tree组件,依然也是用hash来作为这个tree组件的名称,之后cat-file一下这个tree组件,我们发现了最开始提交的两个blob组件,而在tree组件中记录了文件的基本信息。
现在我们应该明白git底层的运行流程了,当我们添加或者修改了文件并且add到Stage Area之后,首先会根据文件内容创建不同的blob,当进行提交之后马上创建一个tree组件把需要的blob组件添加进去,之后再封装到一个commit组件中完成本次提交。在将来进行reset的时候可以直接使用git reset --hard xxxxx
可以恢复到某个特定的版本,在reset之后,git会根据这个commit组件的id快速的找到tree组件,然后根据tree找到blob组件,之后对仓库进行还原,整个过程都是以hash和二进制进行操作,所以git执行效率非常之高。
最后我们再看一个例子,我们创建一个文件夹,然后再文件夹中创建一个文件,这里希望大家跟着我的命令来思考,组件的创建情况。最后来进行验证,看看我们是否真正掌握了git的组件
mkdir test
cd test
echo hello world >> b.txt
这三个命令之后,会创建一个test的文件夹,之后再创建一个b.txt的文件,并且加入hello world这个内容,我们进行提交之后,想想会创建些什么组件?
由于b.txt的内容不一致,所以会创建一个blob组件,我这里是以4a开头的,之后进行提交
我们会发现多了三个组件,按道理来说应该只会创建一个commit组件,之后根据文件信息生成tree组件,最后把blob组件添加进去,应该只会多1个commit和1个tree,为什么会有三个呢?我们通过cat-file来进行查询
我们会发现首先生成了一个commit组件,这个commit中有一个tree,然后tree中处理a.txt和b.txt外还有一个tree组件,这个组件其实就是我们的文件夹,这个tree下面有新增加的b.txt的blob组件。所以我们如果新增加了一个文件夹,就会为这个文件夹创建一个tree组件。
图 3-1. 单个提交对象在仓库中的数据结构
作些修改后再次提交,那么这次的提交对象会包含一个指向上次提交对象的指针(译注:即下图中的 parent 对象)。两次提交后,仓库历史会变成图 3-2 的样子:
图 3-2. 多个提交对象之间的链接关系