为什么要进行版本控制
版本控制的原因
上图是一个CAD设计师的施工图文件夹，他需要修改原来的施工图，但是他又不想把修改前的文件状态和内容给破坏掉，因为如果直接修改，万一修改的有问题，或者后悔修改了，如果以前的文件状态还在的话，大不了把修改糟糕了的删除了就是了，所以他其实就用到了最简单的版本控制方法，那就是复制重命名；
具体写程序的过程也是一样的道理，其实就是一个反复编辑，不厌其烦的编辑的过程。你修改的时候不希望破坏掉修改前的状态，最好就是每修改一段事件，能够保存一个状态，类似系统的自动快照一样，当后面出现问题的时候，可以自由选择复原到之前的某个快照状态；
还有一个原因，那就是，最后发布软件的时候很多时候会有多个版本，而生成软件的源代码却往往只有一份，只是在最后编译生成的时候用到不同的部分，大部分代码还是共用的，所以往往需要版本控制，几个版本复制几个文件夹出来；
版本控制的过程也是过程追踪记录，成就达成的过程。
还有就是很多时候做一个项目，往往不是单枪匹马单打独斗的，是需要很多个人之间合作的，多人合作自然也需要进行多份文档可以编辑，最后再来合并；
当然，上面主要是说明版本控制的方法并不是现在软件行业的版本控制方法，因为缺点很多：
- 首先，需要手工操作复制，慢，繁琐，而且大部分时候我们改动的只是很小的一部分，但每次都要把整个文件夹复制一份出来，这个自然是不合适的。
- 其次，多份快照之间到底有什么不同，这个怎么知道？靠记忆显然扯淡，每个快照附一份说明区别的文件显然也太扯淡了。
- 最后，多个备份的硬盘占用问题；
版本控制的方式
鉴于上面的原因，于是就出现了很多版本控制的工具，这些工具能够做到随时提交快照，并附带上一个小的log说明这次更改的内容；而且控制方式是采用增量的方式，所以项目体积不会占用太多；如果你想知道前后有什么区别，这些工具还能给你提供基于文本对比，给你展示哪些地方进行过修改；如果编辑出问题，可以随时会到之前提交过的任一快照。多人合作，权限控制，多个分支等等，Good and Strong.
集中式版本控制
集中式顾名思义就是代码集中到服务器，用的时候每个人把自己需要的被授权的那部分代码下载到自己的计算机上，提交也是最后提交到服务器上，服务器可以对代码做很好的控制，但是需要有网络，网络断了，就没法工作了。
代表就是SVN,Team Foundation等
分布式版本控制
分布式自然就是每个人的地方多有一份完全的代码，提交和管理都是在本地进行，虽然有远端仓库，不过那是最终提交用的，没联网本地也是完整代码的，只是每次需要最新的代码的时候才必须联网；分布式的代表就是git，对应的网上仓库比较有名的就是github.
版本控制的问题
主要是多个人合作的时候，可能会发生两个人同时提交一个文件的不同更改，这时候版本控制上就会出现冲突，就必须人工介入来决定保留谁的，否决谁的，当然这个事情是由仓库的建立者决定的。
目前的版本控制对文本内容有很好的支持，但是对二进制文件几乎没有支持，所以尽量不要在二进制文件上用这些版本控制工具，这不是他们的长处，二进制文件还是老老实实复制重命名吧，所以说其他设计行业的人苦逼啊。