深度分析Git的内部原理！包管你看不懂

开发者 · 2024-10-3 09:26:05

objects目录就是一个'筐'，git的焦点对象都往内里'装'

objects目录主要存放三种范例的对象，blob、tree、commit，这三种对象是干嘛的，之间的关系放在最后再给各人讲。大概就是blob指定了一个文件、tree形貌目录布局、commit指的终极提交。
天生blob文件(git add)

我们添加一个src/test.txt文件进入暂存区，即实行git add，检察目录布局如下
...|-- objects| |-- 3b| | `-- 18e512dba79e4c8300dd08aeb37f8e728b8dad| |-- info| `-- pack...我们有一个object已经被装入到“筐”中了。我们看到objects目录下是一些以哈希值定名的文件和目录，此中目录由两个字符构成，是每个object hash值的前两个字符。hash值后续的字符串用于定名对应的object文件。在这里我们的object的hash值(实质是sha-1算法)为3b18e512dba79e4c8300dd08aeb37f8e728b8dad，于是这个对象就被放入名为3b的目录下，对应的object文件为18e512dba79e4c8300dd08aeb37f8e728b8dad。
使用git cat-file -t检察object范例，git cat-file -p检察object的内容
$ git cat-file -t 3b18e512dba79e4c8300dd08aeb37f8e728b8dadblob$ git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dadhello world可以发现，这个object的范例是blob，内容就是前面test.txt文件的内容
天生tree、commit文件(git commit)

提交暂存区的变动，实行git commit下令
$ git commit -m "first commit"[master (root-commit) e62c49a] first commit 1 file changed, 1 insertion(+) create mode 100644 test.txt检察.git目录布局如下
...|-- objects| |-- 3b| | `-- 18e512dba79e4c8300dd08aeb37f8e728b8dad //blob| |-- 5a| | `-- cc09a9c845b99fcd7849947502795b784deba8 //tree| |-- c3| | `-- b8bb102afeca86037d5b5dd89ceeb0090eae9d //tree| |-- c8| | `-- 8f34a7728da3d6d5da7e690ba7e8c56b0d41a5 //commit| |-- info| `-- pack...可以发现，相比之前新增了3个目录文件，5a/cc09a9c845b99fcd7849947502795b784deba8
c3/b8bb102afeca86037d5b5dd89ceeb0090eae9d
c8/8f34a7728da3d6d5da7e690ba7e8c56b0d41a5
使用git cat-file -t检察object范例，git cat-file -p检察object的内容
$ git cat-file -t 5acc09a9c845b99fcd7849947502795b784deba8tree$ git cat-file -p 5acc09a9c845b99fcd7849947502795b784deba8040000 tree c3b8bb102afeca86037d5b5dd89ceeb0090eae9d src$ git cat-file -t c3b8bb102afeca86037d5b5dd89ceeb0090eae9dtree$ git cat-file -p c3b8bb102afeca86037d5b5dd89ceeb0090eae9d100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad test.txt$ git cat-file -t c88f34a7728da3d6d5da7e690ba7e8c56b0d41a5commit$ git cat-file -p c88f34a7728da3d6d5da7e690ba7e8c56b0d41a5tree 5acc09a9c845b99fcd7849947502795b784deba8author xxx <xxx> 1621842818 +0800committer xxx <xxx> 1621842818 +0800first commit可以发现4个文件存在某种关系
blob、tree、commit文件的关系

要理清objects目录中各object间的关系，就必须要把握住一个关键概念：“每个commit都是git堆栈的一个快照”

提交新文件时，objects目录布局的厘革

以一个commit为入口，我们能将其时objects下面的全部object接洽在一起。因此，上面4个object中的谁人commit对象就是我们分析各object关系的入口。我们根据上述4个object的内容将这4个object的关系构造为下面这幅表现图:

通过上图我们可以得出结论：

commit是对象关系图的入口；
tree对象用于形貌目录布局，每个目录节点都会用一个tree对象表现。目录间、目录文件间的条理关系会在tree对象的内容中表现；
每个commit都会有一个root tree对象，代表项目根路径;
blob对象为tree的叶子节点，它的内容即为文件的内容

关于这三者的关系算是有点概念了，那么如果我修改了test.txt文件的内容并提交，会发生什么？

修改版本库已存在的文件时，objects目录布局的厘革

我们修改src/test.txt文件的内容，并提交到本地堆栈后，构建出全部object的关系构造表现图：
通过上图我们可以看到：

天生了新的blob对象，其父层的object对象也相应改变；
新天生的commit对象会将第一个commit对象作为parent；

如果在根目录下添加文件并提交，会发生什么？
在已有目录之外新增文件，objects目录布局的厘革

在根目录下新建tes2.txt文件，并提交到本地堆栈后，构建出全部的object的关系构造表现图：

通过上图我们可以看到：

天生了test2.txt文件对应的blob对象，其父层的root tree对象也相应改变；
原来根目录下的src目录对应的tree和blob对象不变；
新天生的commit对象会将第二个commit对象作为parent，如许多个commit对象之间构成一个单向链表；

默克尔树(Merkle Tree)

从上面的三次变动，我们看到无论哪种对象object，一旦放入到objects这个“筐”就是不可变的(immutable)。即便是第二次commit对test.txt举行了修改，git也只是根据test.txt的最新内容创建一个新的blob对象，而不是修改或替换掉第一版test.txt对应的blob对象。
对应目录的tree object亦是云云。如果某目录下的二级目录发生厘革或目录下的文件内容发生改变，git会新天生一个对应该目录的tree对象，而不是去修改原先已存在的tree对象。
默克尔树是一类基于哈希值的二叉树或多叉树，其叶子节点上的值通常为数据块的哈希值，而非叶子节点上的值，是将该节点的全部孩子节点的组合效果的哈希值。默克尔树的特点是，底层数据的任何变动，都会转达到其父亲节点，不停到树根。

branch和tag之以是轻量，因为它们都是“指针”

使用subversion时，创建branch或打tag使用的是svn copy下令。svn copy实行的就是真实的文件拷贝，相称于将trunk下的目录和文件copy一份放到branch或tag下面，创建一个trunk的副本，如许的操纵绝对是“超重量级”的。如果svn堆栈中的文件数量巨大且size很大，那么svn copy实行起来不光速率慢，而且还会在svn server上占用较大的磁盘存储空间，因此使用svn时，打tag和创建branch是要“谨慎”的。

深度分析Git的内部原理！包管你看不懂

浏览过的版块

所属分类: 问答交流

新帖推荐: 30日

推荐作品