深入理解git，从研究git目录开始

转发学习的啦。

似乎很少有人在读某个git快速教程的时候会说：“这个关于git的快速教程太酷了！读完了用起git来超级舒服，并且我一点也不怕自己会破坏什么东西。”

对git的初学者来说，刚接触git时就像进入了一个他不会听/说当地语言的陌生国度。如果你知道自己在哪里并且知道怎么走，那就很好。但是如果你迷路了，那麻烦就大了。

市面上已经有很多关于学习git基本指令的文章，因此这篇文章不讲这个。这里我们将试着从不同的角度来理解。

新手们通常都很害怕git，的确，git确实是一个很强大的工具，但它对使用者并不友好。大量的新概念，一个指令在不同的情况下做完全不同的事情，各种隐含的反馈……

我认为克服这个困难的一个可行方法就是在git的日常commit/puah之外再多做一点工作，如果花点时间来理解一下git是如何产生的，能帮我们避免很多麻烦。

 理解.git

当你建立了一个git repo，使用git init，git便创建了一个奇妙的目录：.git

这个文件夹里包含了git工作时所需要的所有信息。需要明确的是，如果想从你的项目中移除git，但保留项目文件，只需要删除.git文件夹即可。但是，为什么要这样做呢？

|── HEAD

|── branches

|── config

|── description

|── hooks

| |── pre-commit.sample

| |── pre-push.sample

| └── ...

|── info

| └── exclude

|── objects

| |── info

| └── pack

└── refs

|── heads

└── tags

这是你第一次commit之前.git文件夹的样子。

HEAD：这个我们稍后再说。

config：这个文件夹里是你的保存设置，这里将写入远程URL，比如你的邮箱、用户名等。每一次在控制端使用“git config”，它都会在这里结束。

description：被gitweb (Github的原型)用来显示对repo的描述。

hooks：这里有一个有趣的特性。Git有一套可以自动运行在任何一个有意义的git阶段下的脚本，叫做hooks。hooks可以运行在commit/rebase/pull等等状态的之前或之后。脚本的名称决定了它什么时候被执行。一个有用的pre-push脚本的例子将会被运行以测试控制器(远程控制)中的所有样式规则保持一致。

info - exclude：可以将你不想被git处理的文件放到.gitignore文件夹里。被排除的文件可以做到相同的事情，除了它不能被共享。如果你不想将你的自定义IDE关联到congif文件里，就可以使用这个。虽然大部分情况下，.gitignore就足够了。

 commit的内部是什么？

每次你创建了一个文件并跟踪它，git都会将其压缩并存储到自己的数据结构中。这个压缩对象有一个独特的名字、一个哈希码，存储在对象目录下。

在研究对象目录前，我们要问一个问题，什么是commit。这里commit可以看做是工作目录的一种快照，但不仅仅是快照。

实际上当你commit时，git只做两件事情来创造你工作目录的快照：

1. 如果文件没有修改，git仅仅增加压缩文件的名字(hash)到快照中。

2. 如果文件被修改过，git就将其压缩，再将压缩后的文件存储到对象文件夹中。然后再添加这个压缩文件的文件名(hash)到快照中去。

这是一个简化的描述，实际整个过程会复杂一点。

一旦快照文件被建立，它也会被压缩并用hash文件命名。那么这些压缩文件在什么地方呢？答案：对象文件夹。

|── 4c

| └── f44f1e3fe4fb7f8aa42138c324f63f5ac85828 // hash

|── 86

| └── 550c31847e518e1927f95991c949fc14efc711 // hash

|── e6

| └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391 // hash

|── info

└── pack

当我创建了一个名为file_1.txt的空文件并commit之后，对象目录应该是如上所看到的样子。请注意如果你的文件的哈希码是“89faaee…”，git将会吧这个文件储存在名为“89”的子目录下，并且命名这个文件为“faaee…”。

你看到右边有3个hash字样。一个对应的是我的file_1.txt文件，另一个对应的是我commit时所创建的快照文件。那么第三个呢?这是因为commit本身也是一个对象，它也会被压缩并被存储在对象文件夹中。

记住，一个commit指令实际上包含4件事：

• 工作目录的快照文件的名称(哈希码)

• 注释

• 提交者信息

• Parent commit的哈希码

然后，你们可以自己看一下如果不压缩commit文件时会发生什么：

// 查看历史，你会很容易就找到你的commit哈希码

// 你也不必粘贴全部的哈希码，只要足够就可以了

// 创造了独特哈希码的字符串

git cat-file -p 4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828

得到结果：

tree 86550c31847e518e1927f95991c949fc14efc711

author Pierre De Wulf <test@gmail.com> 1455775173 -0500

committer Pierre De Wulf <test@gmail.com> 1455775173 -0500

commit A

你看，正如我们所期望的，我们得到了快照文件的哈希码、作者信息、和我的commit信息。

这里有两件很重要的事情：

• 正如所期望的，那个名为“86550…”的快照哈希文件也是一个对象，并且能够在对象文件夹中被找到。

• 因为这是我的第一个commit，所以没有Parent。

快照文件本质上是什么呢？

git cat-file -p 86550c31847e518e1927f95991c949fc14efc711

100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 file_1.txt

这里，我们找到我们对象存储器中之前存储的最后一个对象，我们快照文件中仅有的对象。这是一个blob，但不是我们今天要讲的。

分支、标签、HEAD，它们都一样。

所以，现在你明白了git中的任何事情都可以用一个正确的hash来得到。现在，让我们来看一看HEAD。那么，HEAD中又有什么呢？

cat HEAD

ref: refs/heads/master

这不是一个哈希码，但它有价值，因为HEAD可以被认为是一个指向你正在使用的分支的指针。现在，我们看一下refs/heads/master内部，我们会看到如下信息：

cat refs/heads/master

4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828

是不是很眼熟？是的，这和我们第一次commit时的哈希码是完全一样的。这说明 branches和tags无非就是一个指向commit的指针。

这意味着你可以删除所有你想删除的branches和tags，而它们所指向的 commit会仍然保留在这里。仅仅是访问commit更困难一点。

现在你应该明白，当你用一堆其它的指令来命令“压缩”你目前的工作目录并储存在对象文件夹时，git实际上都做了些什么。如果你对这些工具足够熟悉，你就应该完全知道哪些文件应该包含在commit中，而哪些文件不应该。

我的意思是commit并不真的是你工作目录的快照，而是你想要commit的文件的快照。那么在你保存你想要commit的文件之前，git将它们保存在哪里呢？它将这些文件保存在索引文件。这里我们就不继续往下深究了，感兴趣的读者请继续研究。