<style></style>

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 代码仓库中的所有文件，包括每个提交的说明信息，目录结构等都会转换成 git 实体

　　所有实体均存在于.git/objects/目录中

　　git中每一个实体以一个40字符长度的十六进制字符串来唯一标识

　　git中包括4种类型的实体：

　　　　1.blob-存储文件内容

　　　　2.tree-存储目录结构和文件名

　　　　3.commit-存储提交的作者、日期、说明等

　　　　4.tag- 存储指向特定提交对象的引用

引用：

　　Git 中，一个分支（branch）、远程分支（remote branch）或一个标签（tag）（也称为轻量标签）仅是指向一个实体的一个指针，这里的实体通常是一个commit实体。这些引用以文本文件的形式存储在目录 .git/refs/ 中符号引用（Symbolic References）Git 有一种特殊的引用，称为符号引用。它并不直接指向一个实体，而是指向另一个引用。举例说，.git/HEAD就是一个符号引用。它指向你正在工作的当前分支。

索引：　　

　　索引是一个暂存区，以二进制文件的形式存储为文件 .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

　　

　　3. git cat-file目录查看该commit实体的内容， 可以看出该commit实体包含了提交的作者及邮箱等全局信息，除此之外还包括了一个tree实体， 该实体的SHA1值为bb527569763dcd71a5dcd4b9a4ba692f1ebb56c0

　　

　　4. 使用git ls-tree查看该tree实体， 发现tree实体中包含了一个blob实体， 该实体的的SHA1值为0cce6dff89d87d991136ad27e18c928eb65f5bb3

　　

 　　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实体

　　　　0cce6dff89d87d991136ad27e18c928eb65f5bb3   ---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

　　之前已经提到过 git 会为每个实体生成一个唯一的 SHA1 值来标识该实体，并且 git 会将生成的实体以二进制文件的形式保存在 .git/objets 目录下，但是 git 在生成 SHA1 时并不是简单地基于文件名、文件路径、创建者及创建时间组合起来，相反 git 是基于内容来生成 SHA1，试想一下，如果我们项目中有一个 a.txt 文件，分别存放在 dir1，dir2 目录下，这时候 git 并不会为 dir1/a.txt 和 dir2/a.txt 文件创建两个 blob 实体，因为 a.txt 虽然在两个目录下，但是他们的内容是完全一样的，所以 git 在生成实体时，通过散列算法，git 会发现这两个文件得出的 SHA1 值是完全一样的，所以 git 只会保存一个 blob 实体。这样可以避免当我们再重命名文件，或者移动文件所在目录时，生成重复的 blob 实体，这也得益于 git 基于内容的散列算法可以很好地发现这两个文件其实是同一个文件。

测试：

　　

 

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 的提交。