git目录
新建一个git项目,查看.git目录
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| .git/
├── branches
├── config
├── description
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── fsmonitor-watchman.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ ├── pre-receive.sample
│ └── update.sample
├── info
│ └── exclude
├── objects
│ ├── info
│ └── pack
└── refs
├── heads
└── tags
9 directories, 15 files
|
objects
我的理解是,项目中你看到的每个东西都是一个object,实际上object有:commit、tree、blob、tag(加tag的时候才会有)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| echo 111 > a.txt
# 此时看git目录没有任何变化
git add .
# 此时看git 目录可以看到多了objects下多了一个目录,运行以下命令:
git cat-file -p 58c9 #xxxx是遗传16进制的值,由目录名和里面的文件名组成
# 输出 111
git cat-file -t 58c9 #可以看到当前objects的类型,此时是blob
# 通过上述的操作,可以知道,blob是一个只包含文件内容的object
# 接下来执行commit操作,此时会发现objects目录下多了两个文件,我们一个一个查看
git cat-file -p 9759 #
# 内容是tree f253233a1a0e59f33115daca3fa494eaa20758d8,还有一些其他信息
# 我们可以看到f253233a1a0e59f33115daca3fa494eaa20758d8也是objects中的一个对象,接着看看它,其实已经可以判断它是一个tree类型
git cat-file -t 9759 #类型是commit
git cat-file -p f253 #内容 100644 blob 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c a.txt
git cat-file -t f253 #类型tree
|
通过以上的信息,实际上一次commit是构建了一棵树。
以上:
9759->f253->58c9 || commit->tree->blob
如果修改a.txt的内容,可以看到会生成新的objects,并且有一个新的blob完全包含了新的a.txt的全部内容,这意味着,git是保存文件的完全的副本,而不是差异。同时会有新的commit object 和 新的tree object。实践吧!
添加了b.txt的objects tree
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| ├── objects
│ ├── 4c
│ │ └── aaa1a9ae0b274fba9e3675f9ef071616e5b209
│ ├── 58
│ │ └── c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c
│ ├── 97
│ │ └── 590a17d455bf791b68561588bddae174d125d1
│ ├── c2
│ │ └── 00906efd24ec5e783bee7f23b5d7c941b0c12c
│ ├── d6
│ │ └── 43f2709193bf972c2d01a0119934e8789ec915
│ ├── f2
│ │ └── 53233a1a0e59f33115daca3fa494eaa20758d8
│ ├── info
│ └── pack
# d643是新的commit,可以看它的内容,会多了一个parent 97590a17d455bf791b68561588bddae174d125d1
# parent 把新的commit和过去的commit连接起来了!
|
可以试着reset一下,会发现其实所有的objects都还在的,只是改变了HEAD等指针;
git的所有内容都是实例和指向它的指针。
[以下在git magic]
blob
Git基于“内容寻址”:文件并不按它们的文件名存储,而是按它们包含内容的哈希值, 在一个叫“blob对象”的文件里。我们可以把文件内容的哈希值看作一个唯一ID,这样 在某种意义上我们通过他们内容放置文件。开始的“blob 6”只是一个包含对象类型与 其长度的头;它简化了内部存储。
这样我可以轻易预言你所看到的输出:文件名是无关的:只有里面的内容被用作构 建blob对象。
你可能想知道对相同的文件会发生什么。试图填加一个你文件的拷贝,什么文件名都行。 在 .git/objects 的内容保持不变,不管你加了多少。Git都只存储一次数据。
以下内容hash值:
"blob" SP "6" NUL "[内容]" LF
以上, blob结构是, 按照文件内容生成的,只要内容相同, 就是同一个blob
tree
“tree”对象:一组包含文件类型,文件名和哈希值的数据。在我们的例 子里,文件类型是100644,这意味着“rose”是一个一般文件,并且哈希值指blob对象, 包含“rose”的内容。其他可能文件类型有可执行,链接或者目录。在最后一个例子里, 哈希值指向一个tree对象。
以上, tree结构是, 包含了文件名/类型(一般文件/可执行/链接/目录),和其指向的对象(目录指向tree, 一般指向blob)
以下内容hash值:
"tree" SP "32" NUL "[文件类型] 文件名" NUL 0xaa823728ea7d592acc69b36875a482cdf3fd5c8d[指向的对象]
commmit
commit 结构, 会包含commit信息/作者等, 会包含父commit指针, 包含tree指针
结构