1. Git三大工作区(工作区、暂存区和版本库)
工作区（WORKING DIRECTORY）: 直接编辑文件的地方，肉眼可见直接操作；
暂存区（STAGIN AREA）：数据（快照）暂时存放的地方；
版本库（GIT DIRECTORT(RESPOSITORY)）：存放已经提交的数据，push 的时候，就是把这个区的数据 push 到远程git仓库了。
git add就是将工作区的修改缓存在暂存区，git commit就是将暂存区的数据快照提交到本地库
这就是为什么 git commit 之前要先执行 git add 的原因,如果不先执行add，那么直接执行commit时不会把当前的修改内容提交到代码库中的。
2. Git 基本概念(实体、引用和索引)
实体：
git中每一个实体以一个40字符长度的十六进制字符串来唯一标识
git中包括4种类型的实体：
1.blob-存储文件内容
3.commit-存储提交的作者、日期、说明等
4.tag- 存储指向特定提交对象的引用
引用：
索引：
索引是一个暂存区，以二进制文件的形式存储为文件 .git/index 中当git add 一个文件，git 将该文件的信息添加到索引中当git commit时，git 仅提交索引文件中列出的文件到 git 本地仓库
实体、引用和索引之间的关系：
测试说明：
1. 新建一个readme,txt并提交到本地库
git add readme.txt git commit -m 'first commit'
2. git log查看commit实体，可以看出对于的SHA1值为999976c43b0e684f1bf7af4bed1acd11b3afa636
4. 使用git ls-tree查看该tree实体， 发现tree实体中包含了一个blob实体， 该实体的的SHA1值为0cce6dffd87d991136ad27e18c928eb65f5bb3
5. 使用git cat-file -p XXX查看blob实体内容， 可以发现blob实体存储的就是readme.txt文件内容
6. 此时我们查看.git/refs/heads/master文件内容，可以发现其刚好为commit实体的SHA1值，也就说明 master 为一个 引用 ，并且指向最后一个 commit 实体
7. 在刚刚介绍中，我们知道了tag实体存储了指向指定commit实体的引用，下面来创建一个标签"version1.1", 通过git rev-parse tagname来查看tag实体的SHA1值，再通过git cat-file -p XXXX可以发现该tag内部即为commit实体，且该commit实体为最后一次提交的实体
8. 至此我们生成了四个实体，分别为
999976c43b0e684f1bf7af4bed1acd11b3afa636 ----commit实体
bb527569763dcd71a5dcd4b9a4ba692f1ebb56c0 ---tree实体
0cce6dffd87d991136ad27e18c928eb65f5bb3 ---blob实体
50e5866a324c6e2afaf6374c39b4b93d394b504a --tag实体
8. 查看各实体、引用、索引的储存位置
实体(.git/objects/):以SHA1头两位作为文件名
引用(.git/refs): heads下存储历史commit实体， tags下存储每一个标签
索引(.git/index)：
通过git ls-files --stage查看.git/index文件内容，可以发现并非存储着最新commit实体的SHA1值，而是其commit实体关联的blob实体SHA1值
再次测试.git/index中文件内容， 我们新建一个文件index并提交到本地库
3. Git SHA1
git 为每一个实体生成一个160位的散列值，通常使用40个字符长度的16进制字符串表示
散列碰撞：
几乎不会出现散列碰撞情况(相同SHA1，出现冲突)
通常情况下你不需要担心该散列值会产生碰撞，对于 160 位数，你有 2160 或者大约 1048 种可能的 SHA1 散列值。这个数有多么巨大，你可以简单感受下，即使你雇一万亿人来每秒产生一万亿个新的唯一 blob 对象，持续一万亿年，你也只有 1043 个 blob 对象，所以你基本不用担心该散列值会产生碰撞，而且只有当不同的内容产生了相同的 SHA1 散列值才能称为碰撞。
git 基于内容的 SHA1：
对应相同的内容得到的永远是相同的 SHA1
测试：
4. git 特殊符号引用介绍
git 自动维护了几个用于特定目的的特殊符号引用。这些引用可以在使用提交的任何地方使用。
- HEAD 始终指向当前分支的最终提交。当切换分支时 HEAD 会更新为指向新分支的最新提交。
- ORIG_HEAD 某些操作，例如 merage / reset 会把 merge 之前的 HEAD 保存到 ORIG_HEAD 中，以便在 merge 之后可以使用 ORIG_HEAD 来回滚到合并之前的状态（在分支合并的时候，产生了冲突，如果已经修改了冲突，并产生了新的提交，但是冲突解决的有问题，想要还原之前的状态重新合并，这时可以使用
git reset --hard ORIG_HEAD来还原到合并之前的状态）。 - FETCH_HEAD 当使用命令
git fetch抓取远程仓库更新时，FETCH_HEAD 保存着最近抓取的分支的 HEAD。 - MERGE_HEAD 当一个合并正在进行时，其他分支的头暂时记录在 MERGE_HEAD 中，换言之， MERGE_HEAD 是正在合并进 HEAD 的提交。