Git对象模型

原文:http://gitbook.liuhui998.com/1_2.html

一、SHA

在git中,所有用来表示项目历史信息的文件,是通过一个40个字符的(40-digit)“对象名”来索引的,对象名看起来像这样:

6ff87c4664981e4397625791c8ea3bbb5f2279a3

你会在Git里到处看到这种“40个字符”字符串。每一个“对象名”都是对“对象”内容做SHA1哈希计算得来的,(SHA1是一种密码学的哈希算法)。这样就意味着两个不同内容的对象不可能有相同的“对象名”。

这样做会有几个好处:

A、Git只要比较对象名,就可以很快的判断两个对象是否相同。

B、因为在每个仓库(repository)的“对象名”的计算方法都完全一样,如果同样的内容存在两个不同的仓库中,就会存在相同的“对象名”下。

C、Git还可以通过检查对象内容的SHA1的哈希值和“对象名”是否相同,来判断对象内容是否正确。

二、对象

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

“blob”用来存储文件数据,通常是一个文件。

“tree”有点像一个目录,它管理一些“tree”或是 “blob”(就像文件和子目录)

一个“commit”只指向一个"tree",它用来标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据,如时间戳、最近一次提交的作者、指向上次提交(commits)的指针等等。

一个“tag”是来标记某一个提交(commit) 。

几乎所有的Git功能都是使用这四个简单的对象类型来完成的。它就像是在你本机的文件系统之上构建一个小的文件系统。

三、与SVN的区别

Git与你熟悉的大部分版本控制系统的差别是很大的。也许你熟悉Subversion、CVS、Perforce、Mercurial 等等,他们使用 “增量文件系统” (Delta Storage systems), 就是说它们存储每次提交(commit)之间的差异。Git正好与之相反,它会把你的每次提交的文件的全部内容(snapshot)都会记录下来。这会是在使用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 63c918c667fa005ff12ad89437f2fdc80926e21c    .gitignore

100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d    .mailmap

100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3    COPYING

040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745    Documentation

100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200    GIT-VERSION-GEN

100644 blob 289b046a443c0647624607d471289b2c7dcd470b    INSTALL

100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1    Makefile

100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52    README

...

就如同你所见,一个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 show 或 git log 去查看某个提交(commit):

$ git show -s --pretty=raw 2be7fcb476

commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4

tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf

parent 257a84d9d02e90447b149af58b271c19405edb6a

author Dave Watson <[email protected].com> 1187576872 -0400

committer Junio C Hamano <[email protected].com> 1187591163 -0700

Fix misspelling of ‘suppress‘ in docs

Signed-off-by: Junio C Hamano <[email protected].com>

你可以看到, 一个提交(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)的内容全部提交.

七、对象模型

现在我们已经了解了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), 这样我们就可以追踪项目每一项提交内容.

八、标签对象

一个标签对象包括一个对象名(译者注:就是SHA1签名), 对象类型, 标签名, 标签创建人的名字("tagger"), 还有一条可能包含有签名(signature)的消息.

你可以用 git cat-file 命令来查看这些信息:

$ git cat-file tag v1.5.0

object 437b1b20df4b356c9342dac8d38849f24ef44f27

type commit

tag v1.5.0

tagger Junio C Hamano <[email protected].net> 1171411200 +0000

GIT 1.5.0

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui

nLE/L9aUXdWeTFPron96DLA=

=2E+0

-----END PGP SIGNATURE-----

关于如何创建和验证标签对象请参考《git tag简介

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

评论这张

转发至微博

时间: 2024-07-29 19:40:33

Git对象模型的相关文章

Git Step by Step – (3) Git对象模型

前面一篇文章介绍了本地仓库的一系列操作,下面我们将进一步了解Git的工作原理,介绍Git对象模型. 刚开始使用Git的时候,对Git对象模型.工作原理并不理解,但是经过一段时间的使用.熟悉之后,然后再来理解这些内容就比较容易了. 下面开始介绍Git对象,然后通过一个实例展示Git对象模型. Git对象 在Git系统中有四种类型的对象,所有的Git操作都是基于这四种类型的对象. "blob":这种对象用来保存文件的内容. "tree":可以理解成一个对象关系树,它管理

Git 对象模型

git诞生 同生活中的许多伟大事件一样,Git 诞生于一个极富纷争大举创新的年代.1991年,Linus创建了开源的Linux,并且有着为数众多的参与者.虽然有世界各地的志愿者为Linux编写代码,但是绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991-2002年间).在这期间,所有的源代码都是由Linus手工合并.因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统(集中式和分布式我们会在接下来的内容讲解)不但速度慢,而且必须联网才能使用.虽然有一

Git Step by Step – (4) 探索.git目录

前面一篇文章介绍了Git对象模型,接下来我们就进入".git"目录看看到底有什么东西,目录中哪些东西又跟Git对象模型相关.结合这个目录,我们将进一步了解Git的工作原理. .git目录 下面就开始进入.git目录了,通过"ls"命令可以看到.git目录中的文件和子目录: 对于这些文件和目录,下面给出了一些基本的描述.在后面后有logs.objects.refs.index和HEAD更详细的介绍 (D) hooks:这个目录存放一些shell脚本,可以设置特定的gi

git/egit 工具使用之——搞笑的引用名称 (funny refname)

一直懒得把项目从svn切换到git的一个重要原因就是不会使用git. 最近觉得必须研究研究了,然后遇到了各种问题,也读了很多文章. 本文讲讲关于 push tag 失败的问题--搞笑的引用名称.错误信息如下: Repository [email protected]:wei.chou/GitUsageTest.git funny refname error: refusing to create funny ref 'v2.1' remotely 操作被拒绝.原因是 "v2.1" 不能

Git版本控制管理学习笔记4-文件管理和索引

    可以认为使用Git时,我们会遇到3个空间:工作目录.索引.版本库.我们关心的,就是在新建.修改等操作时,这三者之间发生了怎样的变化.     笼统的讲,就是在工作目录下编辑,在索引中积累修改,然后把索引中累计的修改作为一次性的变更提交给版本库.     这就意味着,可以在最终提交前添加.删除.移动或者重复编辑文件,只有在提交后才会在版本库里实现累计的变更.     本章将介绍如何管理索引和文件. 一.关于索引的一切: Git的索引不包含任何文件内容,它仅仅追踪你想要提交的那些内容.这一点

Git详解之九 Git内部原理

来自:http://www.open-open.com/lib/view/open1328070620202.html Git 内部原理 不管你是从前面的章节直接跳到了本章,还是读完了其余各章一直到这,你都将在本章见识 Git 的内部工作原理和实现方式.我个人发现学习这些内容对于理解 Git 的用处和强大是非常重要的,不过也有人认为这些内容对于初学者来说可能难以理解且过于复杂.正因如此我把这部分内容放在最后一章,你在学习过程中可以先阅 读这部分,也可以晚点阅读这部分,这完全取决于你自己. 既然已

git中级技能

中级技能(上) 一.实验说明 从本节开始,我们会介绍一些中级和高级的用法,这些用法很少用到,前面三节的内容已经满足了日常工作需要,从本节开始的内容可以简单了解,需要的时候再详细查看. 1.1 下载测试项目环境 通过下列命令获得gitproject项目环境,该项目默认只有一个文件README.md,可以用来进行后续git实验 $ git clone http://git.shiyanlou.com/shiyanlou/gitproject 二.忽略某些文件 1.忽略某些文件 项目中经常会生成一些G

git 安装及命令

一.window下的git安装 1.安装教程 网上教程一堆,我参考的是这个:Git_Windows 系统下Git安装图解 还有这个也不错 2.环境搭建: 在配置完成后,自动加载到系统环境变量中,如我的是:D:\Program Files\Git\cmd 3.配置本地git及生成公钥 安装好Msysgit后,就可以开始配置开发环境了,可以双击Git桌面图标,进入shell后配置name和email,给定一个默认的配置.然后生成公钥: ssh-keygen.exe -C "your@email.ad

(大数据工程师学习路径)第三步 Git Community Book----中级技能(上)

忽略某些文件 1.忽略某些文件 项目中经常会生成一些Git系统不需要追踪(track)的文件.典型的是在编译生成过程中产生的文件或是编程器生成的临时备份文件.当然,你不追踪(track)这些文件,可以 平时不用"git add"去把它们加到索引中. 但是这样会很快变成一件烦人的事,你发现 项目中到处有未追踪(untracked)的文件; 这样也使"git add ." 和"git commit -a" 变得实际上没有用处,同时"git