git操作之版本控制

1. 文档的修改保存

在开始做git笔记之前。我想先想想它是怎么出现的。
在我写文档的时候，常常会有这样的一种情况：
有一天，关于我的文档的第三段，我突然有一个想法，但是我又不想把原来的东西完全否决。所以呢，我在保存文件的的时候，点击另存为，并且命名为：我的文档-修改第三段的想法。此时我的文件夹里面就是这样子的：

后来我有分别在第四段，第五段的上的基础上进行修改，此时我的文件夹就会变成这样。

这是在原来同一文件的不同地方进行修改，目前这种方法还能应付。
有一天，我突然想在原来的文档的第三段上进行修改。为了不重名，我将文档另存为这样

此时，对于在原来的文件上的相同地方进行不同的修改的情况，这样方法已经出现一点问题了，但是还是能勉勉强强能用。但是他们都有一个共同点–在我的文档上修改的。即这个样子的：

存在的问题：修改第三段和修改第三段01存在一定的歧义，以后可能不知道改了哪里。为了解决这个问题，可以做如下修改

这样的话，存在的歧义就会变少了。如果修改过多的话，

已经开始感觉文件很乱了。

前面的情况还只是针对在同一个原始文件上进行修改。在真实场景下，绝对不可能每次都在原始文件上进行修改。还有可能在修改了的情况下修改。比如我现在要在我的文档-修改了第三段文件上进行上述修改。


如果我在我的文档-修改了第三段上进行原来我在我的文档上的修改，那么我的文档的混乱程度可想而知(更别提我又多个文件)。其实，想到这里，问题已经显现出来了：
结合我在每个文件截图下面的思维导图，可以发现我一直在用一个线性表去描述一个树形结构的变化。

2. 如何用一个线性结构去描述一个树形结构的变化

首先，很抱歉起了这样的一个让人误会的标题，一个线性结构是无法去描述一个树形结构的(至少从目前我的知识水平来认为)，否则，树这种数据结构就不会出现了。但是我为什么要取这样一个标题呢？请接着往下看。

还是上面的那个问题。其实还有一种解决办法，前面我们是从文件的角度看待这个问题，他是一种树形变换。但是如果我们从时间的角度看待这个问题，那么它就是一个线性变换的了。就像下面这个样子(请忽略后面的修改日期)：

此时，我们的文档变换就是一种线性的了。但是，这样的话，我们就会损失很多信息。比如文档的变换信息。也许有人会说，我在日期后面再加上一段信息不就行了。就像这个样子：

这样做的话，确实可以携带一部分信息，但是又会陷入原来的问题，无法描述树形变换。当然，这样做的好处是，在原来线性结构的基础上加了一个信息(时间字段)，它可以让我们从时间的角度来看待文档的版本变换。

3. 版本控制

对于前面的问题，我们抽象成如下格式：

那么，版本控制要做的就是对这样一个个的版本块进行控制。