git对象模型
在git系统中有四种类型的对象，所有的Git操作都是基于这四种类型的对象：
"blob":这种对象用来保存文件的内容。
"tree":可以理解成一个对象关系树，它管理一些"tree"和“blob”对象。
"commit":指向一个"tree"，它用来标记项目某一个特定时间点的状态。它包括以下关于时间点的元数据，如时间戳、最近一次提交的作者、指向上次提交等。
"tag":给某个提交增添一个标记。
SHA1哈希值
在Git系统中，每个Git对象都有一个特殊的ID来代表这个对象，这个特殊的ID就是我们所说的SHA1哈希值。SHA1哈希值是通过SHA1算法计算出来的哈希值，对于内容不同的对象，会有不同的SHA1哈希值。
实例
我们以这样的目录结构为例来研究，
--repository //根目录文件夹
--a.txt //txt文件，初始时，内容为a_git
--bb //文件夹
--b.txt //txt文件，在bb文件夹下面，内容为b_git
首先cd repository目录，初始化使用git init命令，执行了这个命令后repository目录下会生成一个.git文件夹，使用find . -type f命令查看目录结构：
然后执行git add -A和git commit -m "commit1"两条命令，可以看到.git/objects/文件夹下增加了五个对象
可是我们的示例工程只有两个文件和一个文件夹，为什么objects里却有五个文件那，这里就要说说commit类型了，commit类型内部可以引用一个tree类型文件和一个commit类型文件。
关于文件的名字，objects内部的文件全部是以sha-1命名，如果是blob类型则以文件内容做sha-1计算得出40字符的校验和，然后为了不让这个objects内部文件过多，所以使用40字符的前两位来建立一个文件夹，在以后38位为文件名，包括commit 和tree 全部使用sha-1校验和来命名。
接下来说一下这五个文件是以什么结构关联的：
每个commit 引用一个tree，根据工程目录结构这个tree 再引用一个blob(a.txt)和一个tree（bb） ，这个tree（bb）则引用一个blob（b.txt）如图：
通过这个图就可以看出来commit，tree，blob的关系了，也基本能明白为什么objects下有五个文件了， 现在我改动一下a.txt然后在提交一个版本，在a.txt添加"123456"内容然后执行add和commit，添加一个版本，接下来再看objects内部的情况：
比刚刚多了三个文件，究竟是哪三个文件？因为我们改动了a.txt文件，所以这里在保留上一个版本的a.txt的基础上新增加一个a.txt文件，git只对有改动的文件进行备份保留。另外两个文件分别是commit 2和一个根tree，现在这8个文件的关系如图:
commit文件内部可以引用一个commit，这样commit之间就可以建立关系了，因为只有a.txt文件做了改动所以只有a.txt文件新建了一个，然后被commit2引用，bb和b.txt文件未做改动则commit2依然引用之前的文件。同理如果我们再改动b.txt文件，我们可以设想一下这些文件的关联关系。如图：
branch分支
git branch 可以获取当前的分支列表，这个分支列表会保存在./git/refs/heads/这个路径下，这里包含master和一些其他分支文件，以master文件为例查看master文件内容如下：
其实这是一个commit类型 的文件名，这样每个分支都可以拥有一个自己的commit引用，从上面的图可以看出只要拿到commit的文件名就可以找到所有跟他关联的文件，还有个问题是./git/refs/heads/这个文件下是所有分支信息，总要有一个当前分支，其实这个当前分支是被记录在./git/HEAD文件内部：
因为当前是master分支所以HEAD文件里记录的是master，每次我们使用git checkout 来切换分支的时候就是在修改HEAD这个文件的内容。那么我们基本就可以理解：我们首先选择一个分支为当前分支，每个分支里记录着当前分支最顶端的commit对象，这个commit对象又可以找到所有跟它关联tree和blob，同时commit对象又和它的历史commit关联。我们可以任意切换当前分支，同时又可以修改当前分支指向的commit对象，比如我们执行reset可以选择回退到任意一个commit。这些就可以顺理成章切换任意分支并且找到任意版本的文件了。