一 、哈希

哈希是一个系列的加密算法，不可逆 根据一个哈希的密文无法得到明文

同一个哈希算法 不管输入数据的数据量有多大得到的哈希加密结果长度固定，如MD5算法 不管输入的是几K的文件还是几G的文件 得到的都是16字节的密文结果 ，常用的加密算法还有SHA1，CRC32 密文结果分别是 20字节和4字节

哈希算法确定，输入数据有变化（哪怕一丁点） 输出结果一定有变化而且通常很大 因此可用于文件校验

二、增量式版本控制SVN & 快照流版本控制git

增量式：以文件变更列表的方式存储信息，每个版本只保存修改的那一小部分，不会存储大量重复数据，可以很好的节约服务器存储。想要得到某个历史版本时只能用当前版本的修改和各个历史版本版本的修改以及原始文件拼接得到。这类系统将其保存的信息看作是一组基本的文件和每个文件随时间逐步积累的差异。

快照流式：将数据看作是小型文件系统的一组快照，每次提commit提交更新git都会对当前版本的所有文件制作一个快照并保存这个快照的索引。为了节约内存 若文件没有修改不再重新存储该文件而是保留一个指向该文件的指针

三、git的提交对象

每次commit提交会有一个提交对象 提交对象里面有一个tree对象，tree对象由当前版本目录下所有文件的哈希值构成。同时提交对象又有自己的哈希值（通过git log可看到）和指向其父对象的指针parent 以及Author Date 等提交信息，提交对象及其父对象形成链条（链表）

四、git的分支管理

初始化本地库时 master分支本身就有 用指针HEAD指向master
分支创建：新建一个指针 testing指向某一个版本（而不是像SVN那样把文件和目录算都复制一遍）

分支切换: 修改HEAD指针 完全不涉及文件的复制，如从指向master到testing 但是指向还是同一个版本 f30ab

当然因为HEAD变了且此时我们在testing分支，若此时再提交的话会影响testing指针但是不会影响master （仍然还是f30ab）

当再切换回master时，修改head重新指向master就可以了 master没变head变

若这时master再提交一次，到这里才真正的出现了分叉c2b9e和87ab2两个分支提交对象，但是他们都指向同一个父对象 f30ab