所有用来表示项目历史信息的文件,是通过一个 40 个字符的（40-digit）“对象名”来索引的，对象名看起来像这样:
6ff87c4664981e4397625791c8ea3bbb5f2279a3
你会在 Git 里到处看到这种“40 个字符”字符串。每一个“对象名”都是对“对象”内容做 SHA1 哈希计算得来的，（SHA1 是一种密码学的哈希算法）。这样就意味着两个不同内容的对象不可能有相同的“对象名”。
这样做会有几个好处：
每个对象(object) 包括三个部分：类型，大小和内容。大小就是指内容的大小，内容取决于对象的类型，有四种类型的对象："blob"、"tree"、 "commit" 和"tag"。
几乎所有的 Git 功能都是使用这四个简单的对象类型来完成的。它就像是在你本机的文件系统之上构建一个小的文件系统。
Git 与你熟悉的大部分版本控制系统的差别是很大的。也许你熟悉 Subversion、CVS、Perforce、Mercurial 等等，他们使用 “增量文件系统” （Delta Storage systems）, 就是说它们存储每次提交(commit)之间的差异。Git 正好与之相反，它会把你的每次提交的文件的全部内容（snapshot）都会记录下来。这会是在使用 Git 时的一个很重要的理念。
一个 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 对象有一串(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 对象"指向一个"tree 对象", 并且带有相关的描述信息。
你可以用 --pretty=raw 参数来配合 git show 或 git log 去查看某个提交(commit):
$ git show -s --pretty=raw 2be7fcb476
commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4
tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf
parent 257a84d9d02e90447b149af58b271c19405edb6a
author Dave Watson <dwatson@mimvista.com> 1187576872 -0400
committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700
Fix misspelling of 'suppress' in docs
Signed-off-by: Junio C Hamano <gitster@pobox.com>
你可以看到, 一个提交(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)，这样我们就可以追踪项目每一项提交内容。
$ git cat-file tag v1.5.0 object 437b1b20df4b356c9342dac8d38849f24ef44f27 type commit tag v1.5.0 tagger Junio C Hamano <junkio@cox.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/" 开头的引用罢了)。
