版本控制已经出现有些年头了。然而，我还是会被人问起一些，诸如版本控制是什么或者它是如何工作的，这样基础的问题。本文会概括地解释版本控制解决的重要问题，本文使用的场景针对的是源代码版本控制。

目前有很多不同类型的版本控制系统（Version Control System， VCS）。一些VCS，比如Subversion和CVS，以中央仓库（repository）为中心进行架构。此外，还有分布式的VCS（Distributed VCS，DVCS）， Git 和 Mercurial 是两个新近出现的DVCS。然而，在上述两种类型的环境中，通常会有一个“指定的”中央仓库。对应地，比如一个Subversion服务器或者一个GitHub仓库。下面会基于这个场景进行图示说明。那么让我们开始吧。

在开发者拷贝到本机之前，服务器需要创建一个仓库。创建初始仓库会由于产品不同而有所差别。从现在起，你所要知道的就是，在服务器上有一个初始空间。我把这个版本称作版本“A”。

现在，每个开发者（开发者1和开发者2）都会拷贝版本“A”到他们本地电脑。再一次地，从服务器拷贝的过程会由于产品不同采用的技术会有所差别。

每个开发者会在他们的本地拷贝上进行开发。他们的本地拷贝基于版本“A”。然而，由于他们应该不会做同样的开发，因而他们的版本会有所差别。因此，会有2个以上的版本会同时被创建，比如版本“B”和版本“C”。


开发者1首先完成了她的工作并提交到服务器。服务器上的当前版本被更新成版本“B”。


开发者2现在完成了他的工作并试图提交到服务器。然而，这是服务器告知他基于开发的版本已经发生改变。这也是为什么采取版本控制的首要原因之一。这个特性是对网络共享代码然后由开发者手动更新的一个跨越式发展，这确保了之前的编辑没有被新的修改覆盖。


开发者2必须首先获得所有版本“B”的变化，并合并到他的修改中，然后才可以提交到服务器。这个过程听起来有些复杂。然而，大多数现代的版本控制系统十分高级，能够自动在开发者的本地拷贝上完成合并。有几种情况会产生冲突（例如：开发者1和开发者2同时修改了同一个文件的同一行）。这就是一些VCS产品比其他更高级的地方。不论如何完成合并，现在开发者2在他们的本地系统上同时混合了版本B和版本C。


现在开发者2可以提交他的版本到服务器。

这是一个版本控制的基础。通过注意观察图中服务器的连线可以发现版本控制的原理。服务器记录了所有先前的版本包括发生的变化，什么时候发生以及由谁进行修改。当需要进行代码回溯或者引入其他bug时，这个记录能够解除困境。
我希望本文能够为版本控制系统提供一个基础的介绍。如果你有任何疑问，请就你问题发表评论。
 
英文原文：greenmoonsoftware 

该文章在 2012/4/27 22:43:13 编辑过