From past to now
这周在公司的通知邮件里看到了关于SVN下线一年，即将彻底清空公司所有SVN库的提醒。突然有了个想法，这里就梳理梳理版本管理工具的迭代史吧~
还是老样子，难免疏漏，若有偏差，欢迎各位大佬指正
正文
why exist?
为什么会有版本管理工具出现呢？
相信大家都遇到过类似的一个问题：我写一套代码或者软件，最初的版本做完了后，又因为一些原因要进行更新。这时候我们有时想要在保存了原本版本的基础上，再更新出一个新版本。通常我们就会另存一个"XXX-更新"了事。但是之后如果又有新更新了，我们又会另存一个"XXX-第二次更新"；同时，如果还和其他人协作，命名也就更麻烦，并且协作的另一方电脑里的版本也很难控制和整理……不仅如此，有时胡乱取了名字保存了，还会出现不知道哪个是最新版本的情况。当然，这个时候可以在把文档选中看文件的更新时间解决，但是若有频繁的更新，不仅仅会看着很乱，还会占用我们电脑许多的存储空间。为了解决这个问题，版本管理工具就应运而生啦。
time flies...
时光飞逝，版本管理工具也经理过多次迭代，这里就简要梳理下从CVS到SVN，再到GIT的变迁史吧
tell me the story.
CVS
现在能了解到的较早并常用的版本控制软件应该就是CVS了。
CVS是一个C/S（Client/Server）结构的代码控制软件。一看用户端-服务端就明白，这个软件处理版本更迭的方法就是设置一个主服务器管理所有版本的迭代。
比如，程序员A，B和C一起写代码。他们在自己的电脑里安装了CVS用户端软件，并且在一台服务器上建立了一个用于存放代码的源代码库。当A完成了初版程序后，他会将这个程序的所有源代码通过CVS软件提交到库里。B要使用A的代码时，就要从库里down下来A的代码，再在他本地进行更改，更改完后再提交到源代码库里，若C更改则同理。这样就实现了多人协作开发。
但是若仅有以上功能，那就太low了。
CVS还提供了以下内容：
-
允许同时更改代码：
当A从库里下载下代码版本Old，在更新代码的途中，而B也要进行更改怎么办呢？你可能想：那就B先改呗！不过这样就会导致一个问题，最后提交的人会完全覆盖掉前一个人的更改，因为A和B都是基于版本1更改的代码，若允许同时更改，A先提交了版本New A，B又在之后提交了版本New B，New B版本中没有New A中更改的数据，最终会导致覆盖。
所以在CVS之前，版本控制系统都有签入签出记录：这部分代码被A拿去改啦，其他人直到A改完，都不能动这部分代码！~
而CVS就解决了这个问题。它拥有自动合并的功能，会检索出文件的不同点，并进行合并。当然，如果有不能安全处理的地方，它也会提醒程序员们自己来进行手工合并。
-
同文件保存所有版本&允许版本回退：
有时候你可能发现最新版本的代码被B还是C或者哪个蠢蛋改错了，导致一系列崩溃无法运行。这个时候就需要你进行版本回退啦。CVS会在你的文件里加入一些额外信息，以记录每个版本。如果你需要回滚代码，很简单——找到想要回退到的版本，跳转过去就行了。（当然，这需要花费一些时间）。
SVN
SVN(Subversion)是一个开源的代码版本控制系统，设计的目标就是取代CVS。现在仍有部分公司和企业在使用SVN用于版本管理。
从CVS更迭到SVN有诸多因素，比如能够重构以及对目录进行操作等等，并且因为CVS是单向差异文件传输而SVN为双向，使得后者会比前者快很多。细节也有不少，
简要概括下，SVN有以下的特点：
-
同样的C/S结构：
这个没有多少变化。（也是之后Git改进的要点） -
速度快：
CVS因为架构的问题，速度比较缓慢，而SVN在这里做出了改进。它在网络上仅传输很少的信息。但是相应的它需要巨大的存储空间，因要完全备份所有的工作文件。 -
能够对目录进行操作：
过去CVS是无法对目录进行操作的，删除文件夹这种事情只有库的admin才能跑到服务器上删除。 -
简单易懂：
CVS的配置弄起来特别的复杂，而SVN配置起来就简单多了。 -
更智能的差异比较：
自动化实现的升级~
这里贴一个较为详细的资料，喜欢的同学可以多了解：
SVN与CVS两者间的比较
Git
终于到Git了，这也是目前使用比例最大的版本控制系统了~
Git与前两者最大的不同点就是采用分布式而非集中式。
集中式就如同CVS和SVN，版本库是要集中放在中央服务器的，程序员A要更新文档or代码时，就要先从中央服务器down下来最新版本，更新完后再上传上去。而分布式版本控制系统没有中央服务器，每个人的电脑上都有一个完整的版本库！
这里摘抄廖雪峰老师所写——传送门
集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。
集中式版本控制系统
那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。
Git-分布式版本管理系统
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
这里还有Git诞生的轶事，也是特别的有趣，有兴趣的同学可以传送。这里就不贴啦（一贴上来就全搬过来了，廖雪峰老师写得太好，没什么可改的(〃ﾉωﾉ)）
Git的诞生-廖雪峰的官方网站
Git自己的特点，这里总结下，有如下几点：
分布式
不必联网，避免网速烦恼；不用早上上班pull下班push，想啥时候更新就啥时候更新（当然最好每次更改都尽快提交，要不然管理员催死你啊(｀・ω・´)）。先进的版本管理——使用指针
Git是使用指针来管理版本的，关于指针，学过C++的同学都知道。
当你退回版本时，实际上只是更改了指针的指向，这就比前两个老前辈在速度上有了质的提升。
同时，这也就代表Git支持回滚版本。Crash？没事！直接回滚~把head指针直接指向完好的版本就OK！
分支管理
程序员A想要做软件正式版，程序员B想要在软件正式版制作的同时拉出来一个Pro版，程序员C想要做一个Lite版。怎么办？使用三个库？
Git使用了分支管理，允许创建多个分支，你可以使用一个库管理同一代码的不同版本，而且，想合并merge时，随时奉陪~标签管理
程序自己生成的版本名称又臭又长，举例——版本号1829asdJ01t，输入时是不是特别麻烦？Git拥有标签管理的功能，给你的稳定版本取个标签吧~ Beauty1.0，这样是不是就很好找啦~
更多关于Git的详细的资料可以去廖雪峰老师的官网了解~这也是我认为最好的教程网站之一啦。
以上~
