图文并茂，详细讲解Git底层存储原理

自从小学妹学完定时任务后（详情请看上篇文章），对我那是百般仰慕，遇到问题第一时间就会想到我（是的，要的就是这种效果）。这不，小学妹今天又找我了，今天的问题是什么呢？听我细细道来…

原来小学妹在公司中，用的是 Git的代码管理工具（还不知道这个软件的要面壁啦~）。有一天不知道发生什么了，文件夹中所有代码都被删掉了，但是只留下本地一个 .git文件夹，这可把小学妹急坏了，刚写完一个大功能，还没来得急提交到远程服务器，明天就要开始内测了，重写已经来不及了…

听完小学妹的诉求后，我慢悠悠的跟她说：小事儿一桩，交给学长，一秒钟搞定！

你想知道怎么搞定的？先来了解下 Git底层代码存储原理吧！

一、 git工作流程原理分析：
假定现在我们有一个 git仓库，在这个 git仓库中已经添加了两个文件分别叫做 file1和 file2，两个文件中的内容分别是 foo和 bar。并且都做了 commit操作。这时候的图如下：

在 Git中，从理解上来讲是分成三种区，分别是工作目录、暂存区以及Git仓库。其中工作目录是我们写代码的文件，暂存区是已经把代码进行了 add操作，但是并没有进行 commit操作。Git仓库则是已经把代码提交到仓库中了，只要仓库不丢失，代码是不会丢失的了。

再来理解下 add操作和 commit操作分别做了什么事。用上图的例子来说，工作目录中包含了 file1和 file2，然后在做 add操作的时候，理解上来讲是说把代码提交到了暂存区，实际上 Git是将代码修改了的部分进行了记录，然后进行 SHA1操作，生成了一个 blob对象（ blob是一个类似文件对象的二进制数据，不懂可以理解为一个快照），把存储到仓库中了（注意，此时代码快照实际上已经存储到仓库中了），但是并没有在目录树上进行映射，而是在一个索引文件中进行了映射。此后如果我们再执行 commit操作，才会把索引中的映射，真正更改到对象树中，对象树会记录所有的 commitid与 blob的映射