1、版本控制

1.1 什么是版本控制

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况，以及回溯的系统。任何类型的文件都可以进行版本控制。

比如作为一个位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本，采用版本控制系统（VCS）是个不错的选择。

有了它你就可以将某个文件回溯道之前的状态，甚至将整个项目都回退到过去某个时间点的状态，可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致问题出现的原因，又是谁再何时报告了某个功能的缺陷等等。

使用版本控制系统还意味着：就算你胡乱把一个项目的文件增删改，也照样能轻松恢复到原先的样子。

1.2 本地版本控制系统

很多人习惯用复制整个项目目录的方式来保存不同版本，或许还改名字加上备份时间表示区别。这么做的唯一好处是简单，但是容易犯错。比如有时候会混淆所在工作目录，不小心会写错文件或者覆盖文件。

为了解决这个问题，有人开发了多种本地版本控制系统，大都是采用某种简单的数据库来记录文件的历次更新差异。

Figure 1.本地版本控制
其中最流行的一种叫做RCS，现今许多计算机系统上还有它的踪影。他的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）。通过应用所有的补丁，可以重新计算出各个版本的文件内容。

1.3 集中化的版本控制系统

我们都知道，不可能总是一个人在开发，合作开发是一个必然的结果。那么，问题来了：如何让在不同系统上的开发者系统工作？

集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。这类系统，诸如CVS、Subversion以及Perforce等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。

Figure 2. 集中化的版本控制
这种做法带来了很多好处，每个人可以在一定程度上看到项目中的其他人正在做什么。而管理员也可以轻松掌握每个开发者的权限，并且管理一个CVCS要远比在各个客户端上维护本地数据库来得轻松。

这么做最显而易见的缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作了。如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问将丢失左右数据，包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。本地版本控制系统也存在类似的问题，只要整个项目的历史纪录被保存在单一位置，就有丢失左右历史更新记录的风险。

1.4 分布式版本控制系统

基于上述问题，于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）问世。在这类系统种，像Git、Merfurial、Bazaar以及Darcs等，客户端并不只是提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这样一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来地本地仓库恢复。因为每一次克隆操作，实际上都是一次对代码仓库地完整备份。

Figure 3. 分布式版本控制
许多这类系统都可以指定和若干不同地远端代码仓库进行交互。那么，就可以在同一个项目中分别和不同工作小组地人相互协作。可以根据需要设定不同地协作流程，比如层次模型式地工作流，而这在以前的集中式系统中是无法实现的。

2、几种版本控制工具比较

2.1 VSS

VSS 的全称为 Visual Source Safe 。作为 Microsoft Visual Studio 的一名成员，它主要任务就是负责项目文件的管理，几乎可以适用任何软件项目。管理软件开发中各个不同版本的源代码和文档，占用空间小并且方便各个版本代码和文档的获取,对开发小组中对源代码的访问进行有效的协调。

优点：
VSS作为一款历史悠久的版本管理工具，在早期扛起了版本管理系统方面的大气，能帮助解决一部分版本控制方面的问题，也在一定程度上帮助解决代码共享方面的难题。
缺点：
1.文件大多会以独占的形势进行锁定。如果一个人在修改的时候其他人没有办法进行修改。
2.VSS只支持Windows版本，且只兼容微软的开发工具。
3.文件存储，服务器必须共享文件夹，对文件的安全性没有足够保障。

2.2 SVN

SVN是Subversion的简称，目前是Apache项目底下的一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。简单说，SVN就是用于多个人共同开发同一个项目，共用资源的目的。

优点：
（1）集中式管理，管理方式再服务端配置好，客户端只需要同步提交即可，使用方便，操作简单，很容易就可以上手。
（2）在服务端统一控制好访问权限，利用代码的安全管理。
（3）所有代码以服务端为准，代码一致性高。
（4）又良好的目录级权限控制系统。
缺点：
（1）所有操作都需要通过服务端进行同步，这回导致服务器性能要求比较高。如果服务器宕机就无法提交代码了。

（2）分支管理不灵活，SVN分支是一个完整的目录，且这个目录拥有完整的实际文件，这些操作都是在服务端进行同步的，不是本地化操作，如果要删除分支，也是需要将远程的分支进行删除的，这会导致大家都得同步。

（3）需要联网。如果无法连接到SVN服务器，就无法提交自己的代码，更别说还原、对比等操作了。而且如果是通过外网同步，速度很慢。

（4）不适合开源开发。

2.3 Git

Git是Linus Trovalds大神的作品，是一个开放源码的版本控制软件。与SVN最大的区别，就是分布式的管理。分布式相较于集中式的最大区别是：开发者可以提交到本地，每个开发者通过克隆（Git clone），在本地机器上拷贝一个完整的Git仓库。

优点：
（1）分布式开发时，可以Git clone克隆一个本地版本，然后在本地进行操作提交，本地可以完成一个完整的版本控制。在发布的时候，使用Git push来推送到远程即可。

（2）Git分支的本质是一个指向提交快照的指针，速度快、灵活，分支之间可以任意切换。都可以在本地进行操作可以不同步到远程。

（3）冲突解决，多人开发很容易就会出现冲突，可以先pull远程到本地，然后在本地合并一下分支，解决好冲突，在push到远程即可。

（4）离线工作，如果Git服务器出现问题，也可以在本地进行切换分支的操作，等联网后再提交、合并等操作。
缺点：
（1）Git没有严格的权限控制，一般是通过系统设置文件的读写权限来做权限控制。

（2）工作目录只能是整个目录，而SVN可以单独CheckOut某个有权限的目录。

（3）Git上手可能没有SVN那边顺手，需要经过学习一下。

总结

如果对访问控制、权限分配和代码安全性等要求比较高的，建议使用SVN。

如果是分布式，多人开发，版本迭代比较快的项目，建议使用Git。