版本控制的基本概念-以Subversion为例-1

版本控制系统存储了所有的代码，存储这些代码的地方叫做项目仓库（repository），这个仓库可以放在本机或者专门的服务器下。要注意这个仓库的定期备份工作。通过文件系统或者网络系统可以访问仓库，SVN采用的网络的方式。

一般情况下我们说版本控制的是代码部分，但是实际操作上所有用于构建、发布程序的文件和配置等信息都需要在版本控制工具的控制下，而所有的生成文件（依赖代码生成的，如文档）都不需要放在仓库中。

把仓库中的代码拷贝到我们电脑上，进行修改，这称为工作拷贝（working copy），对于大项目来说，拷贝所有的代码显然并不现实，这需要对仓库的项目进行分割。至于如何分割，SVN以目录的形式分割项目仓库。第一次建立工作拷贝时叫做签出（checking out）。除了签出还有一个概念是导出（export）导出的只是一个项目仓库文件的快照。我们在本地修改代码之后，需要提交到服务器上，这个过程叫做提交（committing）。为了确保一致性，在提交之前你需要进行更新操作，就是和本地代码比较服务器端代码，看着和上次取出来的数据有什么不同地方（主要是团队对代码的修改是否影响到我的部分），这个过程叫做更新（update）。

项目仓库在我们看来会存储我们修改过的没一个版本，但实际上并不是这样，他只是存储了最新的版本以及之前修改的增量过程。同时Subversion存储了必要的历史版本，以提供最快的存取速度。CVS使用时每个文件都有一个版本号，而SubVersion则不是这样，它对项目仓库进行整体编号，这样我们就能将每个版本号视为代码的一个断面。

CSV的版本号                                                SVN的版本号

所谓版本2.1.12.23，谁知道这是什么东西！？比不上QQ2012这来得好记吧。我们可以使用标签来跟踪代码开发中的重要事件，例如新功能的导入、架构的改变等等。

与分支（branching）对应的概念是主干（trunk），比如我们需要在目前所有开发人员持续修改的QQ软件上发布一个新的版本QQ2013，我们不可能要求所有工作人员停止更新，等待代码发布出去在增加新功能、修改BUG。所以引入了分支，这相当于创建了一个平行于现有代码的另一份代码，变成了一个双头并进的队伍。主团队依然在原来的主干上工作，发布团队则在分支上工作，修改BUG，增添新功能、发布后的维护。这种功能的缺点就是你制造了一个双头蛇，之后不过瘾，又制造了一个双头蛇，再制造，继续制造，继续制造……你一定学过数据结构中的树……控制这种“爆炸”的方法就是只为发布建立分支。更令人吃惊的是这种爆炸居然是可以收敛的。这就是合并（merging），合并可以把代码从分支合并到主干上，可以在分支之间合并，可以在多个分支之间合并。比如我们在发布的QQ2013上发现了一个BUG，那么这个BUG极有可能存在于之前发布的QQ2012和当前的主干上，于是我们修改了发布版上的BUG，合并到主干上。