教程目录
一、什么是版本控制
版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一。
简而言之：版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
配置文件:在计算机科学领域，配置文件是一种计算机文件，可以为一些计算机程序配置参数和初始设置。
软件配置管理:软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
你可以把一个版本控制系统（缩写VCS）理解为一个“数据库”，在需要的时候，它可以帮你完整地保存一个项目的快照。当你需要查看一个之前的快照（称之为“版本”）时，版本控制系统可以显示出当前版本与上一个版本之间的所有改动的细节。
版本控制与项目的种类，使用的技术和基础框架并无关系：
-
无论是设计开发一个HTML网站或者是一个应用软件，它的工作原理都是一样的。
-
你可以选择任何你喜欢的工具来工作，它并不关心你用什么样的文本编辑器，绘图程序，文件管理器或其他工具。
因此不要混淆版本控制的备份系统和一般的部署系统。当你开始尝试在你的项目中使用版本控制，你不需要替换和改变开发过程中使用的那些常用工具。
二、为什么要使用版本控制
-
在我们的实际开发过程中，经常会有这种需求或问题：
我们需要在已经发布的程序中添加新的功能，如果测试验证后没有问题，才会使用新的代码，而在测试验证期间，不能影响原来的代码。我们常用的方式应该就是备份多份源代码。这么做唯一的好处就是简单，但是特别容易犯错。
实际项目开发基本都是多个人合作完成，在多个人写代码时，就牵扯到代码合并成一份的问题。
-
软件开发中采用版本控制系统是个明智的选择。
版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。
有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某 个时间点的状态。就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以 轻松恢复到原先的样子。但额外增加的工作量却微乎其微。
你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。
三、版本控制内容
版本控制包括：检入检出控制、分支和合并、历史记录。
检入检出控制
软件开发人员对源文件的修改不能在软件配置管理库中进行，对源文件的修改依赖于基本的文件系统并在各自的工作空间下进行。为了方便软件开发，需要不同的软件开发人员组织各自的工作空间。一般说来，不同的工作空间由不同的目录表示，而对工作空间的访问，由文件系统提供的文件访问权限加以控制。
访问控制需要管理各个人员存取或修改一个特定软件配置对象的权限。开发人员能够从库中取出对应项目的配置项进行修改，并检入到软件配置库中，对版本进行“升级”；配置管理人员可以确定多余配置项并删除。
同步控制的实质是版本的检入检出控制。检入就是把软件配置项从用户的工作环境存入到软件配置库的过程，检出就是把软件配置项从软件配置库中取出的过程。检人是检出的逆过程。同步控制可用来确保由不同的人并发执行的修改不会产生混乱。
分支和合并
版本分支(以一个已有分支的特定版本为起点，但是独立发展的版本序列)的人工方法就是从主版本——称为主干上拷贝一份，并做上标记。在实行了版本控制后，版本的分支也是一份拷贝，这时的拷贝过程和标记动作由版本控制系统完成。版本合并(来自不同分支的两个版本合并为其中一个分支的新版本)有两种途径，一是将版本A的内容附加到版本B中；另一种是合并版本A和版本B的内容，形成新的版本C。
历史记录
版本的历史记录有助于对软件配置项进行审核，有助于追踪问题的来源。历史记录包括版本号、版本修改时间、版本修改者、版本修改描述等最基本的内容，还可以有其他一些辅助性内容，比如版本的文件大小和读写属性。
四、版本控制系统分类
纵观版本控制系统的发展历史，《Version Control By Example》一书的作者 Eric Sink 在他的书中对版本控制进行了分类，广义上讲，版本控制工具的历史可以分为三代：
| 代 | 网络 | 操作 | 并发性 | 示例 |
|---|---|---|---|---|
| 第一代 | 无 | 仅一个文件 | 锁定的 | RCS, SCCS |
| 第二代 | 集中式 | 多文件 | 提交之前合并 | CVS, SourceSafe, Subversion, Team Foundation Server |
| 第三代 | 分布式 | 变更的集合 | 合并之前提交 | Bazaar, Git, Mercurial |
本地版本控制系统
第一代版本控制系统被称为本地版本控制系统。通过加锁将并发执行转换成顺序执行。 一次只能有一个人处理文件。具体流程如下：首先，应该把文件放在一个服务器上，方便使用者上传或下载文件；其次，任何人想对文件修改时，需要先把这个文件加锁，通过checkout指令，使得其他人无法修改；最后，当修改完成之后，需要释放锁，通过checkin指令，形成一个新的版本，存放到服务器端。
第一代版本控制系统主要有 RCS、SCCS（1972年发布）和 DSEE（被认为是 Atria ClearCase 的前身）。目前，有些项目还在使用！
悲观锁 每次获取数据的时候，都会担心数据被修改，所以每次获取数据的时候都会进行加锁，确保在自己使用的过程中数据不会被别人修改，使用完成后进行数据解锁。由于数据进行加锁，期间对该数据进行读写的其他线程都会进行等待。
集中式版本控制系统
第二代版本控制系统被称为集中式版本控制系统（Centralized Version Control Systems，CVCS），其对同步修改更加宽容，但有一个明显的限制，用户必须在允许提交之前将当前修订合并到他们的工作中。
集中化的版本控制系统诸如 CVS，svn 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到 这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。
这种做法带来了许多好处，现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统; 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。 如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。
并不是说服务器故障了就没有办法写代码了,只是在服务器故障的情况下,编写的代码是没有办法得到保障的.试想 svn 中央服务器挂机一天.你还拼命写了一天代码,其中 12 点之前的代码都是高质量可靠的,而且有很多闪光点.而 12 点之后的代码由于你想尝试一个比较大胆的想法,将代码改的面目全非了.这样下来你 12 点之前做的工作也都白费了 有记录的版本只能是 svn 服务器挂掉时保存的版本!
注：单点故障（英语：single point of failure，缩写SPOF）是指系统中一点失效，就会让整个系统无法运作的部件，换句话说，单点故障即会整体故障。
要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端偶然提取出来的保存在本地的某些快照数据就成了恢复数据的希望。但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。 只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
由上图可看到，在集中式版本控制系统中，如果服务器嗝屁了，那么所有的开发者就只能干瞪眼了！因为，SVN 对于项目的管理是依赖于服务器中的中心仓库的！我们的更改必须要提交到服务器中的中心仓库。
乐观锁 每次获取数据的时候，都不会担心数据被修改，所以每次获取数据的时候都不会进行加锁，但是在更新数据的时候需要判断该数据是否被别人修改过。如果数据被其他线程修改，则不进行数据更新，如果数据没有被其他线程修改，则进行数据更新。由于数据没有进行加锁，期间该数据可以被其他线程进行读写操作。 乐观锁一般会使用版本号机制或 CAS 算法实现。
分布式版本控制系统
第三代版本控制系统被称为分布式版本控制系统（Distributed Version Control Systems，DVCS），其允许合并和提交分开。在每个使用者电脑上就有一个完整的数据仓库，没有网络依然可以使用。
在这类系统中，像 Git，BitKeeper 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一 来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本 地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份（Git团队对代码做了极致的压缩 最终需要的实际空间比svn多不了太多）。
由上图可看到，分布式版本控制系统也可以有个服务器端的仓库，用来同步各开发者的私有仓库！在分布式版本控制系统中，每个参与者的本地也会有一个完整的仓库。即使服务器端崩溃，我们仍然可以使用 Git（仅在本地仓库管理我们的代码），在网络具备时，再和服务器进行同步即可！
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中分别和不同工作小组的人相互协作。
分布式的版本控制系统在管理项目时存放的不是项目版本与版本之间的差异（集中式版本控制系统存储的是差异）.它存的是索引(所需磁盘空间很少 所以每个客户端都可以放下整个项目的历史记录)。
分布式的版本控制系统出现之后,解决了集中式版本控制系统的缺陷:
断网的情况下也可以进行开发(因为版本控制是在本地进行的)
使用 github 进行团队协作,哪怕 github 挂了 每个客户端保存的也都是整个完整的项目(包含历史记录)
五、版本控制总结
集中式
svn因为每次存的都是差异，需要的硬盘空间会相对的小一点，可是回滚的速度会很慢
优点: 代码存放在单一的服务器上 便于项目的管理
缺点:
服务器宕机: 员工写的代码得不到保障
服务器炸了: 整个项目的历史记录都会丢失
分布式
git每次存的都是项目的完整快照 需要的硬盘空间会相对大一点(Git团队对代码做了极致的压缩 最终需要的实际空间比svn多不了太多 可是Git的回滚速度极快)
优点:完全的分布式
缺点:学习起来比SVN难
13
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
