基本概念
　　 版本控制是一个非常简单的概念，我举个例子简单说明一下你就能大概明白它是一个什么东西，当你不会版本控制的时候：

你的BOSS决定做一款灰常牛逼的软件，找你进行开发

当你做好之后，老板又突发奇想觉得加入一个新功能就更好了

当你添加上新功能之后，老板觉得该功能可能又不太好，让你去掉它

当你去掉这个功能的时候，老板说铁汁，你还是把它加上来吧，我突然觉得这个功能又挺好的

你心里想老板我不干了，你自己来弄吧，但是现实确让你抱起键盘乖乖就范

　　 [图片]

　　 这个时候聪明的同学可能会这个样子做，在做完基本功能后进行拷贝，再到拷贝的副本上做出修改添加上新功能，这样不管老板怎么奇思妙想你都有应对之策：

　　 [图片]

　　 那么这就是一个最简单的版本控制了，是不是非常简单？
历史发展
　　 版本控制大概经历了四个阶段，如下：

文件夹拷贝
本地版本控制
集中式版本控制
分布式版本控制
　　 文件夹拷贝

　　 这个不必多说了，相信傻子都明白，正如上面示例中提到的对原产品进行拷贝后再添加新功能。

　　 这个也确实是很长一段时间中的解决方案，但是它有一个非常大的问题，比如我原产品的代码有十万行，我的新功能有两万行，那么我的原产品（V1）加上我的新功能（V2）就要有二十二万行代码进行存储，非常的浪费存储空间（V1十万行，V2十二万行）。
本地版本控制

　　 到了后面，逐渐的出现了一些软件，它可以帮助我们做版本控制，而并非由我们手动进行拷贝。

　　 并且，它有以下几个特点：

　　 1.同一时间只能看到一个版本，如果你想回到之前版本，就可以通过其命令等操作方式进行回滚

　　 2.不会很干脆的进行拷贝，而是在原有代码的基础上进行增量更新，这意味着我两个版本的存储总代码量只有十四万行，非常节约空间

　　 记住，第一个特点十分的具有代表性，那么下面放上一张Git官网的图片，你可以清晰的看见，同一时间我们只能看到一个文件，但是在版本库中会存储多个版本：

　　 [图片]

　　 集中式版本控制

　　 慢慢的，大家都开始发现单兵作战不能解决全部的问题，我们需要共同生产。

　　 所以当有多名开发者同时进行开发时，就需要有一个公共的仓库来进行存放代码,那么现在的代码都会提交至一个共有仓库中，这样一来就解决了协同开发的问题，但是相应的，如果存放共有仓库的计算机一宕机，那么大家都不能进行生产了，如果情况更加糟糕比如共有仓库中的磁盘损坏，那么大家这么久以来的辛苦就全都白费了。