理解Git暂存区

　　文件.git/index是一个包含文件索引的目录树，像是一个虚拟的工作区。在这个虚拟工作区的目录树中，记录了文件名和文件的状态信息。以便快速检测文件的变化。                                                              索引中还包含所有Blob类型的SHA-1标识符。文件的内容没有存储在其中， 而是保存在Git对象库.git/objects目录中，文件索引建立了文件和对象库中对象实体之间的对应，                                                       如图，展示了工作区、版本库中的暂存区和版本库之间的关系。

- 图中左侧为工作区，右侧为版本库。在版本库中标记为index的区域是暂存区，标记为master的是master分支代表的目录树。

- HEAD实际是指向master分支的一个“游标”，所以图示的命令中出现的HEAD的地方可以用master来替代。

- objects标志的区域为Git的对象库，实际位于.git/objects目录下。

- 工作区修改（或新增）文件执行git add命令时，暂存区的目录树将被更新，同时工作区修改（或新增）的文件内容会被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的索引文件中。

- 执行提交操作（git commit）时，暂存区的目录树会写到版本库（对象库）中，master分支会做相应的更新，即master最新指向的目录树就是提交时原暂存区的目录树。

- 执行git  reset HEAD命令时，暂存区的目录树会被重写，会被master分支指向的目录树替换，但是工作区不受影响。

- 执行 git rm --cached <file>命令时，会直接从暂存区删除文件，工作区不做改变。

- 执行 git checkout. 或 git checkout -- <file>命令时，会用暂存区全部的文件或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。

- 执行 git checkout HEAD ,或 git  checkout HEAD <file> 命令时，会用HEAD指向的master分支中的全部或部分文件替换暂存区和工作区中的文件，这个命令也是极具危险性的，因为不但会清除工作             区中未提交的改动，也会清楚暂存区中为提交的改动。

分支

　　Git 在进行提交操作时，会创建一个提交对象（commit object）。该提交对象会包含一个指向提交内容快照的指针、作者的姓名和邮箱、提交时输入的信息以及
指向它的父对象的指针。首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象。

　　假设一个工作目录，包含了三个将要被暂存和提交的文件。 暂存操作会为每一个文件计算校验和（使用我们在 起步 中提到的 SHA-1 哈希算法），
然后把当前版本的文件快照保存到Git 仓库中（objects，Git 使用 blob 对象来保存它们），将校验和加入到暂存区域等待提交：

　　当使用 git commit 进行提交操作时，Git 会先计算每一个子目录（本例中只有项目根目录）的校验和，然后在Git 仓库中这些校验和保存为树对象。
Git 会创建一个提交对象，它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。如此一来，Git 就可以在需要的时候重现此次保存的快照。

现在，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照）、一个树对象（记录着目录结构和 blob 对象索引）以及一个提交对象（包含着指向前述树对象的指针                                                              和所有提交信息）。

Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之后，你其实已经有一个指向最后
那个提交对象的 master 分支。 它会在每次的提交操作中自动向前移动。

分支创建

　　$ git branch testing         #创建一个 testing 分支 
　　

创建Testing分支会在当前所在的提交对象上创建一个指针。

可以简单地使用 git log 命令查看各个分支当前所指的对象。 提供这一功能的参数是 --decorate。

正如你所见，当前 “master” 和 “testing” 分支均指向校验和以 f30ab 开头的提交对象。

分支切换
　　要切换到一个已存在的分支：  
　　　　　　　　　　　　

这样 HEAD 就指向 testing 分支了。

现在不妨再提交一次：

　　

如图所示， testing 分支向前移动了，但是 master 分支却没有，它仍然指向运行 git checkout 时所指的对象。 这就有意思了，
现在我们切换回 master 分支看看：

　　

这条命令做了两件事。 一是使 HEAD 指回 master 分支，二是将工作目录恢复成 master 分支所指向的快照内容。

我们不妨再稍微做些修改并提交：
　　 

你可以简单地使用 git log 命令查看分支历史。 运行 git log --oneline --decorate --graph--all ，它会输出你的提交历史、各个分支的指向以及项目的分支分支情况。

由于 Git 的分支实质上仅是包含所指对象校验和（长度为 40 的 SHA-1 值字符串）的文件，所以它的创建和销毁都异常高效。创建一个新分支就相当于往一个文件
 中写入 41 个字节（40 个字符和 1 个换行符），如此的简单能不快吗？

这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。 完成这样繁琐的过程通常需要
好几秒钟，有时甚至需要好几分钟。所需时间的长短，完全取决于项目的规模。而在 Git 中，任何规模的项目都能在瞬间创建新分支。 同时，由于每次提交都会记录父对象，
所以寻找恰当的合并基础（译注：即共同祖先）也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。