一、哈希
??哈希是一个系列的加密算法，各个不同的哈希算法虽然加密强度不同，但是有以下几个共同点：
??①不管输入数据的数据量有多大，使用同一个哈希算法，得到的加密结果长度固定
??②哈希算法确定，输入数据确定，输出结果保证不变
??③哈希算法确定，输入数据有变化，输出结果一定有变化，而且通常变化很大
??④哈希算法不可逆
??⑤哈希算法中不区分英文大小写
??哈希算法有很多种，如：MD5、SHA-1等。Git 底层采用的是 SHA-1 ，因为哈希算法可以被用来验证文件，Git 就是靠这种机制来从根本上保证数据完整性的
二、Git保存版本的机制
?1、集中式版本控制工具(如SVN)的文件管理机制：以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件(对应下图的Version1)和每个文件随时间逐步累积的差异(对应下图的其他Version)，在文件管理的时候只保存当前版本相对于上一个版本的差异，这是一种增量式的版本控制
?2、Git 的文件管理机制：Git 把数据看作是小型文件系统的一组快照。每次提交更新时 Git 都会对当前的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。所以 Git 的工作方式可以称之为快照流。下图中Version2及其之后的实线框中的文件表示该版本的该文件相较于上个版本有变动，虚线框中的文件表示该版本的该文件相较于上一版本没有变动(只保存上一个版本的指针，而无需保存文件)，这样根据当前版本的文件和指向上一版本的指针就可以找到该版本的所有文件的状态
?Git 的提交对象：
?提交对象及其父对象形成的链条：
三、Git的分支管理机制(依赖于指针的变化)
?1、分支的创建：创建一个指向HEAD当前指向的分支的当前版本的指针
??说明：此时HEAD指向master分支的f30ab版本，那么新创建的testing分支的指针也会指向master分支的f30ab版本，实际上是创建的分支的指针会指向HEAD指针指向的分支所在的版本
?2、分支的切换：仅仅是改变HEAD指针的指向
??说明：切换分支时，仅仅是切换一下HEAD指针的指向，从原分支指向想切换的分支
?3、版本的提交
??说明：若此时在testing分支上提交了版本，则只会使该分支的指针向后移动，不会影响其他分支，如上图所示，其他分支的指针指向并没有发生变化
?4、冲突的产生
??说明：在testing分支修改后，再将HEAD切换至master，然后在master上修改相同的文件，然后再master分支上提交，就会形成下面的局面：这时就有可能产生冲突，这合并版本的时候就需要解决冲突
5、和SVN的比较
??SVN在创建分支的时候是将所有文件复制一份，而git仅仅是创建一个指向当前版本的指针，因此效率很高；Git中分支之间的切换仅仅是HEAD指针的变化，效率也很高；
??综上：Git的操作很依赖于HEAD指针的变化。