GIT的对象模型

SHA

所有用来表示项目历史信息的文件,是通过一个40个字符的(40-digit)“对象名”来索引的,对象名看起来像这样:
6ff87c4664981e4397625791c8ea3bbb5f2279a3
你会在Git里到处看到这种“40个字符”字符串。每一个“对象名”都是对“对象”内容做SHA1哈希计算得来的,(SHA1 是一种密码学的哈希算法)。这样就意味着两个不同内容的对象不可能有相同的“对象名”。

这样做会有几个好处:
- Git只要比较对象名,就可以很快的判断两个对象是否相同。
- 因为在每个仓库(repository)的“对象名”的计算方法都完全一样,如果同样的内容存在两个不同的仓库中,就会存在相同的“对象名”下。
- Git还可以通过检查对象内容的SHA1的哈希值和“对象名”是否相同,来判断对象内容是否正确。

对象

每个对象(object) 包括三个部分:类型,大小和内容。大小就是指内容的大小,内容取决于对象的类型,有四种类型的对象:“blob”、“tree”、 “commit” 和"tag"。

  • “blob”用来存储文件数据,通常是一个文件。
  • “tree”有点像一个目录,它管理一些“tree”或是 “blob”(就像文件和子目录)
  • 一个“commit”只指向一个"tree",它用来标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据,如时间戳、最近一次提交的作者、指向上次提交(commits)的指针等等。
  • 一个“tag”是来标记某一个提交(commit) 的方法。
    几乎所有的Git功能都是使用这四个简单的对象类型来完成的。它就像是在你本机的文件系统之上构建一个小的文件系统。

Blob对象

一个blob通常用来存储文件的内容.

可以使用git show命令来查看一个blob对象里的内容。假设我们现在有一个Blob对象的SHA1哈希值,我们可以通过下面的的命令来查看内容:

$ git show 6ff87c4664
Note that the only valid version of the GPL as far as this project is
 concerned is _this_ particular version of the license (ie v2, not v2.2 
 or v3.x or whatever), unless explicitly otherwise stated.

一个"blob对象"就是一块二进制数据,它没有指向任何东西或有任何其它属性,甚至连文件名都没有.
因为blob对象内容全部都是数据,如两个文件在一个目录树(或是一个版本仓库)中有同样的数据内容,那么它们将会共享同一个blob对象。Blob对象和其所对应的文件所在路径、文件名是否改被更改都完全没有关系。

Tree 对象

一个tree对象有一串(bunch)指向blob对象或是其它tree对象的指针,它一般用来表示内容之间的目录层次关系。

git show命令还可以用来查看tree对象,但是git ls-tree能让你看到更多的细节。如果我们有一个tree对象的SHA1哈希值,我们可以像下面一样来查看它:

$ git ls-tree fb3a8bdd0ce
100644 blob 71fcf244d84eae6e661b1f90e727ff33b2cc07e7	.gitignore
100644 blob b7c78bacf381b9416a36cb717628c7733fc45892	README.md
100644 blob 537785bdbe785d43e7df32ed38b2dd7709b9a44a	analysis_options.yaml
040000 tree c435592837725c6ebee428c8633dddfa365d421e	android
040000 tree 956f7cacc80a9a0248a182e85e495e4a70e3fba4	ios
040000 tree 9f5f649a13d8d485d3ef8e769b871bcbf3aa1a9c	lib
100644 blob 8a034cf7d8863b3ec758d7047cd1eb8d0316192a	pubspec.lock
100644 blob 3e6ee524a40b18ed70c2b2e6db7d16338b15873d	pubspec.yaml
040000 tree a27aab757205249b221e77b70f943f87491945fb	res
040000 tree dfeeaa2290e2b39512cdef399aa50490869c7d3d	structure
040000 tree 00f4da87a06370c3b8fb0bb9ed65fceff85d7a58	test

就如同你所见,一个tree对象包括一串(list)条目,每一个条目包括:mode、对象类型、SHA1值和名字(这串条目是按名字排序的)。它用来表示一个目录树的内容。
一个tree对象可以指向(reference): 一个包含文件内容的blob对象, 也可以是其它包含某个子目录内容的其它tree对象. Tree对象、blob对象和其它所有的对象一样,都用其内容的SHA1哈希值来命名的;只有当两个tree对象的内容完全相同(包括其所指向所有子对象)时,它的名字才会一样,反之亦然。这样就能让Git仅仅通过比较两个相关的tree对象的名字是否相同,来快速的判断其内容是否不同。

注意:在submodules里,trees对象也可以指向commits对象. 请参见 Submodules 章节
注意:所有的文件的mode位都是644 或 755,这意味着Git只关心文件的可执行位.

Commit对象

commit对象指向一个tree对象, 并且带有相关的描述信息.

可以用 --pretty=raw 参数来配合 git showgit log 去查看某个提交(commit):

git show -s --pretty=raw cd30dbbfed2fdf2b5c6b4a4368a6d3933abc458b
commit cd30dbbfed2fdf2b5c6b4a4368a6d3933abc458b
tree f6c47af91881f516e240dc877f381c3cab019457
parent 195bda08da140ca9c38fbd5a0085284b0e84a7d7
author wangrundong <**@**.com> 1612339117 +0800
committer wangrundong <**@**.com> 1612339117 +0800

    ***** 修复字幕漏掉没有变色的问题

    Change-Id: I658e083ad2213e79687f41b12b4928c29d1a77ef

一个提交(commit)由以下的部分组成:

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

注意: 一个提交(commit)本身并没有包括任何信息来说明其做了哪些修改; 所有的修改(changes)都是通过与父提交 (parents)的内容比较而得出的. 值得一提的是, 尽管git可以检测到文件内容不变而路径改变的情况, 但是它不会去显式(explicitly)的记录文件的更名操作. (你可以看一下 git diff 的 -M 参数的用法)

一般用 git commit 来创建一个提交(commit), 这个提交(commit)的父对象一般是当前分支(current HEAD), 同时把存储在当前索引(index)的内容全部提交.

Tag对象

一个标签对象包括一个对象名(译者注:就是SHA1签名), 对象类型, 标签名, 标签创建人的名字(“tagger”), 还有一条可能包含有签名(signature)的消息. 你可以用 git cat-file 命令来查看这些信息:

git cat-file tag tag_0.7.0.44

object 82777260bb0b708d5b5bdb365a3ed69824f18df3
type commit
tag tag_0.7.0.44
tagger wangrundong <**@**.com> 1612440167 +0800

tag_0.7.0.44_v1.5.0

注意: git tag 同样也可以用来创建 “轻量级的标签”(lightweight tags), 但它们并不是标签对象, 而只一些以 “refs/tags/” 开头的引用罢了

对象模型

现在我们已经了解了3种主要对象类型(blob, tree 和 commit), 好现在就让我们大概了解一下它们怎么组合到一起的.
如果我们一个小项目, 有如下的目录结构:

$>tree
.
|-- README 
`-- lib
	|-- inc
	| 	`-- tricks.rb 
	`-- mylib.rb
2 directories, 3 files

如果我们把它提交(commit)到一个Git仓库中, 在Git中它们也许看起来就如下图:

可以看到: 每个目录都创建了 tree对象 (包括根目录), 每个文件都创建了一个对应的blob对象 . 最后有一个commit对象来指向根tree对象(root of trees), 这样我们就可以追踪项目每一项提交内容.

与SVN的区别

Git与大部分版本控制系统的差别是很大的。也许你熟悉Subversion、CVS、Perforce、Mercurial 等等,他们使用 “增量文件系统” (Delta Storage systems), 就是说它们存储每次提交(commit)之间的差异。Git正好与之相反,它会把你的每次提交的文件的全部内容(snapshot)都会记录下来。这会是在使用Git时的一个很重要的理念。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值