Git Step by Step (4)：探索.git目录
目录
前面一篇文章介绍了Git对象模型，接下来我们就进入”.git”目录看看到底有什么东西，目录中哪些东西又跟Git对象模型相关。结合这个目录，我们将进一步了解Git的工作原理。
.git目录
下面就开始进入.git目录了，通过”ls”命令可以看到.git目录中的文件和子目录：
对于这些文件和目录，下面给出了一些基本的描述。在后面后有logs、objects、refs、index和HEAD更详细的介绍
- (D) hooks：这个目录存放一些shell脚本，可以设置特定的git命令后出发相应的脚本；在搭建gitweb系统或其他git托管系统会经常用到hook script
- (D) info：包含仓库的一些信息
- (D) logs：保存所有更新的引用记录（会在后面介绍引用）
- (D) objects：所有的Git对象都会存放在这个目录中，对象的SHA1哈希值的前两位是文件夹名称，后38位作为对象文件名
- (D) refs：这个目录一般包括三个子文件夹：heads、remotes和tags，heads中的文件标识了项目中的各个分支指向的当前commit
- (F) COMMIT_EDITMSG：保存最新的commit message，Git系统不会用到这个文件，只是给用户一个参考
- (F) config：这个是Git仓库的配置文件
- (F) description：仓库的描述信息，主要给gitweb等git托管系统使用
- (F) index：这个文件就是我们前面文章提到的暂存区（stage），是一个二进制文件
- (F) HEAD：这个文件包含了一个当前分支（branch）的引用，通过这个文件Git可以得到下一次commit的parent
- (F) ORIG_HEAD：HEAD指针的前一个状态
Git引用
Git中的引用是个非常重要的概念，对于理解分支（branch）、HEAD指针以及reflog非常有帮助。
Git系统中的分支名、远程分支名、tag等都是指向某个commit的引用。比如master分支，origin/master远程分支，命名为V1.0.0.0的tag等都是引用，它们通过保存某个commit的SHA1哈希值指向某个commit。
重新认识HEAD
HEAD也是一个引用，一般情况下间接指向你当前所在的分支的最新的commit上。HEAD跟Git中一般的引用不同，它并不包含某个commit的SHA1哈希值，而是包含当前所在的分支，所以HEAD直接指向当前所在的分支，然后间接指向当前所在分支的最新提交。
为了更形象的解释上面的描述，我们首先查看”.git/HEAD”的内容：
|
1
|
ref: refs/heads/master
|
这就表示HEAD是一个指向master分支的引用，然后我们可以根据引用路径打开”refs/heads/master”文件，内容如下：
|
1
|
4ea6c317a67e73b0befcb83c36b915c1481f2efe
|
根据前面一片文章的介绍，我们通过这个哈希值查看对象的类型和内容，可以看到这个哈希值对应一个commit，并且通过”git log”可以发现这个commit就是master分支上最新的提交。
所以可以看到，所有的内容都是环环相扣的，我们通过HEAD找到一个当前分支，然后通过当前分支的引用找到最新的commit，然后通过commit可以找到整个对象关系模型，看下图：
引用和分支
直到现在我们都没有开始介绍分支（branch），这里也不准备介绍分支，只是想大概展示一下引用和分支的关系。
假设我们现在除了master分支，又创建了一个release-1.0.0.1的分支，再次查看”.git/refs/heads/”目录，可以看到除了master文件之外，又多了一个release-1.0.0.1文件，查看给文件的内容也是一个哈希值。
通过”git show-ref –heads”命令就可以产看所有的头，这些都是HEAD的候选值：
根据前面的讲解，这个commit就是就是release-1.0.0.1分支上最新的提交。同样，当我们把当前分支切换到release-1.0.0.1的时候，HEAD文件的内容也会相应的变成：
|
1
|
ref: refs/heads/release–1.0.0.1
|
再看reflog
看过第二篇文章的同学一定还记得我们是怎么根据reflog去得到一个commit哈希值，然后把repo退回到一个指定的状态。
接下了，我们进入”.git/logs”文件夹，可以看到这个文件夹也有一个HEAD文件和refs目录，些就是记录reflog的地方。
查看HEAD文件的内容，发现这个文件将会包含所有分支的reflog记录：
|
1
2
3
4
|
0000000000000000000000000000000000000000 601b527296fea232c84b3661abcbff0576b1272c WilberTian <Wilber***.com> 1419759347 +0800 commit (initial): add calc.py into repo
601b527296fea232c84b3661abcbff0576b1272c c2163e267380f71373f29f922e7089abbb741772 WilberTian <Wilber***.com> 1419769538 +0800 commit: add sub function in calc.py
c2163e267380f71373f29f922e7089abbb741772 4ea6c317a67e73b0befcb83c36b915c1481f2efe WilberTian <Wilber***.com> 1419771391 +0800 commit: add app.py, __init__.py and calc.py
4ea6c317a67e73b0befcb83c36b915c1481f2efe 4ea6c317a67e73b0befcb83c36b915c1481f2efe WilberTian <Wilber***.com> 1419822744 +0800 checkout: moving from master to release–1.0.0.1
|
进入”.git/logs/refs”目录，同样会有master和release-1.0.0.1两个文件，两个文件将会保存各自分支的reflog记录
master的内容：
|
1
2
3
|
0000000000000000000000000000000000000000 601b527296fea232c84b3661abcbff0576b1272c WilberTian <Wilber***.com> 1419759347 +0800 commit (initial): add calc.py into repo
601b527296fea232c84b3661abcbff0576b1272c c2163e267380f71373f29f922e7089abbb741772 WilberTian <Wilber***.com> 1419769538 +0800 commit: add sub function in calc.py
c2163e267380f71373f29f922e7089abbb741772 4ea6c317a67e73b0befcb83c36b915c1481f2efe WilberTian <Wilber***.com> 1419771391 +0800 commit: add app.py, __init__.py and calc.py
|
release-1.0.0.1的内容：
|
1
|
0000000000000000000000000000000000000000 4ea6c317a67e73b0befcb83c36b915c1481f2efe WilberTian <Wilber***.com> 1419822744 +0800 branch: Created from master
|
Git索引（index）
前面文章我们也提到过index/stage，就是更新的暂存区，下面就来看看index文件。
index（索引）示一个存放了已排序的路径的二进制文件，并且每个路径都对应一个SHA1哈希值。在Git系统中，可以通过”git ls-files –stage”来显示index文件的内容：
从命令的输出可以看到，所有的记录都对应仓库中的文件（包含全路径）。通过”git cat-file”命令查看app.py对应的哈希值，可以看到这个哈希值就是代表app.py的blob对象。
现在我们更新app.py文件，加上一个”div(16, 4)”的调用并通过”git add”添加到暂存区，这时发现index中app.py对象的哈希值已经变化了。
通过这个例子，我们也可以理解diff操作应该会有怎样的输出了：
- git diff：比较WorkSpace和stage，add之前有diff输出；add之后没有diff输出
- git diff HEAD：比较WorkSpace和repo，add之前之后都有diff输出
- git diff –cached：比较stage和repo，add之前没有diff输出；add之后有diff输出
对象的存储
前面提到所有的Git对象都会存放在”.git/objects”目录中，对象SHA1哈希值的前两位是文件夹名称，后38位作为对象文件名。
所以，我们前面提到的master上最新的commit对象的哈希值是”4ea6c317a67e73b0befcb83c36b915c1481f2efe”，那么这个对象会被存储在”.git/objects/4e/a6c317a67e73b0befcb83c36b915c1481f2efe”。进入objects目录后，我们确实找到了这个文件。
在Git系统中有两种对象存储的方式，松散对象存储和打包对象存储。
松散对象（loose object）
松散对象存储就是前面提到的，每一个对象都被写入一个单独文件中，对象SHA1哈希值的前两位是文件夹名称，后38位作为对象文件名。
打包对象（packed object）
对于松散存储，把每个文件的每个版本都作为一个单独的对象，它的效率比较低，而且浪费空间。所以就有了通过打包文件（packfile）的存储方式。
Git使用打包文件(packfile)去节省空间.。在这个格式中,，Git只会保存第二个文件中改变了的部分，然后用一个指针指向相似的那个文件。
一般Git系统会自动完成打包的工作，在已经发生过打包的Git仓库中，”.git/objects/pack”目录下会成对出现很多”pack-***.idx”和”pack-***.pack”文件。关于打包就介绍这么多了，暂时还没有去研究两个文件的内容和原理。
总结
这篇文章结合了前一篇的Git对象模型，探索了.git文件夹，通过引用，reflog以及索引的介绍，相信会对Git的工作原理有了更多的了解。
通过这两篇文章介绍下来，感觉对谜一样的Git也慢慢的熟悉了起来。
转载自：http://blog.jobbole.com/84652/
