28.Git版本数据管理机制.avi原创

哎，我们下边呢，来说一说gate是怎样来管理各个版本的历史数据的，我们每一次把修改提交到本地库以后，都会产生一个新的历史记录啊，那这个版本的各个版本的历史记录呢，其实在不同的版本控制系统当中呢，它有不同的策略来保存，比如说呢，我们sun这种集中式版本控制系统哈，它是这样做的。它每一个版本呢，其实只是保存啊，这个每个文件呢，它有修改的这一小部分，就是说你你你所做的修改，它给保存起来，每一个版本都是，那么你将来想要某一个历史版本的这个数据的时候。那么我就拿我当前的这个修改，当前版本的修改和历史版本的修改，以及你原始的文件给它们拼到一块儿，哎，把这一套呢，拼到一块儿给你，哎这这就是能够拿到呢，我当前这个版本的这个文件的状态。那么我们说呢，SN这种机制哈，它叫增量式的版本控制啊，我不是我不会去保存大量的重复的数据，我每个版本呢，都是保存这个有变化的这一点啊，这个这个做法呢，能够很好的节约我们服务器的存储的空间。

而我们这个gate呢，和它有很大的区别啊，它是一种快照流，每个版本呢，其实是对我们整个呃本地库里边哈，或者说我们呃工作区里边所有文件的所有目录，所有文件哈，去给他拍一个快照。诶，然后呢，去保存成我们这个版本，当然你如果只是仅仅保存一个快照的话呢，这里边也一定会有这个重复的文件，你比如说呢，我们这里边儿哈，你看这个fair a改了一次以后变成A1啊，然后呢，A1呢，到下一个版本到三的时候呢，这个没有改啊，那么这个在下一个版本，在下一个版本才改成这个A2，那么这个时候呢，其实这个A1呢，因为他没有改，他这个地方保存了一个指针指向上一个版本的这个A1。

啊，你像这个B呢，没有改指向它原始的这个B啊，这个版本也没有改指向它原始的B，所以说呢，它重复的文件呢，它会有指针指向之前的那个文件啊，它是一种这个基于快照的方式去管理各个版本的，那么这个里边这个细节哈，我们刚才前面为什么要说哈希这个事儿呢，我们就是要说哈，这个他管理文件的这个细节。比如说呢，这是一个，比如说这是我们在get里边这个一个提交的一个对象哈，它里边你每次提交的时候呢，都会去创建这样一个提交对象，这个提交对象包含什么内容呢？你的每一个文件，诶，其实呢，我都会去哈希以后呢，得到一个哈希值，这个哈希值当然只是局部了啊，它不是一个不是完整的哈，只是其中的一个片段，呃，最前面那几位每一个文件呢，都会去做一个哈希，得到一个哈希值。

然后呢，所有的目录里边的这些文件呢，他们的哈希值构成一个数对象，你看这有一个是吧？哎，这有一个数对象，数对象里边呢，就包含每一个具体的这个文件，以及呢，这个文件的哈希值。它自己呢也会有一个哈希值，然后呢，这个对象呢是提交对象，提交对象里边呢，就包括这个数对象，你看这个tree就21C2就指向它，诶那么这个提交对象呢，它有又有一个自己的这个哈希值，那么我们在这个K里边呢，大家看我们get log的时候，我们能够看到呢。他每一个提交呢，都有一个提交对象，就是这个commit后边啊，会有这样一个哈提值，其实这个哈值呢，就是这么来的，诶嗯，大家。也可能听说过哈这个比特币，其实这个比特币呢，它内部呢，管理这个交易哈，和我们getate里边呢，去管理文件啊，它有非常大的这个相似点，那么我们呃，Gate里边的每一个文件，相当于我们比特币管理的数据里边的一个交易啊，比特币呢，它是把所有的这个交易呢，两两去做哈希，当然每一个也要做哈希哈，然后两两再去做哈希，一直呢给他归并为最后的一个哈希啊，然后呢，这就是一个区块，呃，每一个区块里边呢，还要去保存上一个区块的哈希啊，再保存下一个区块的哈希，所以它整个呢就构成了一个，呃，通过哈希这种加密算法，构成了一个非常严密的严谨的一个数据的链条，其中的任何一个数据呢，只要你做过哈希了，我区块确认过了，那么就不能够再修改了，不允许再有任何的修改啊，因为你其中修改一丁点数据，后边整个数据呢，他的哈希校验就都不能够。

通过了，我们这儿也是每一个版本，你看这不是snapho a就是这个A快照，Snap shop BB快照，C快照，那么每一个快照里边哈，你看它会有一个parent，它会去指向它的呃负节点啊，或者说呢，其实是它的呃按提交对象来说呢，就是它的负对象，你看这个当前我们34AC2呢，它的负节点就是这个98C9就是它啊所以说呢，你这个各个版本怎么就能够形成一个历史记录呢，就是通过这个各个版本之间的这个父子关系啊，所建立的这个联系。

哎，这个里边呢，还会有，你看这个除了这个信息哈，就是这个commit这个信息，呃，对象的信息，它的副对象的信息，当前这次提交的作者啊，当前提交的这个提交者啊，这些信息构成了一个完整的提交对象，就是我们这样一个snap shot啊，这是这个get里边呢，对于我们这个。各个版本的历史数据呢，它有这样一个存储化和管理的这个机制。