zhangge's stupid and messy life

关于SCM项目管理，VCS版本控制的理解以及集中式与分布式的区别理解

06 Mar 2013

版本控制系统（Version Control System），就是控制我们项目的版本系统。古老的做法是，几个人开发一个项目，完成一些功能以后，通过email或者其他工具传到其他人那里，而且还要规定不允许修改对方负责的代码。明显看到缺点很多，麻烦，慢，不小心修改别人的文件，只有一个最终版本，不方便测试，管理不方便……这样子软件配置管理就成了一个学科，版本控制是里面的核心。

版本控制的发展历史很长，是先从集中式开始的。有了一个版本控制软件以后，在服务器上运行一个仓库，主要用来存放代码，他使用链表形式管理，每个节点就是一个版本，注意的是，每个节点是差异存储的。在开发者本地有一个工作空间，就是编写代码，做测试，当开发者完成一些功能或者修复一些bug以后，这就是一个更改集，然后把这个更改集提交到仓库里面去；然后其他开发者就可以把这个功能，也就是更改集更新到自己的工作空间里面去了。这样就方便了管理，我们也可以在服务器上随便下载一个版本，知道每个版本的差异等，协同开发的效率大大提高。

为什么叫更改集不叫版本？版本是对于发布来讲，一般是说基线上的更改集，要标记特定的版本号。普通开发是在分支上面进行的，每次提交是一个更改集。

以上是集中式的版本控制，典型的使用就是svn。后面出现了分布式的版本控制软件，也就是说，每一个开发者的本机都是一个仓库，每个开发者之间都是平等的，完全摆脱了中央服务器的约束，当然，我们是很有必要设置一个中央仓库来管理源码的。分布式的版本控制软件典型的是Hg，Git。

分布式最大的好处就是离线工作，不仅意味着可以不联网就享受版本控制的好处，并且也意味着普通的提交速度也要快的多，而且，以此带来的巨大灵活性甚至能改变你的工作方式，因为以前集中式的版本控制系统，每次提交都会影响到他人，以至于不能提交未经测试的版本，而使用分布式的版本控制系统时，你可以随时随地的本地提交，安全的保护自己的工作成果，以防意外，也能随时随地的本地clone，本地分支，本地就是一套完整的版本控制系统！直到修改到最终版本，然后才push（相当于集中式版本控制的commit）到真正的一个公用库上去。

但是，在特定情况下，即使整个团队已经熟练使用分布式VCS，也最好选择Subversion。这就是当使用二进制，VCS无法合并的时候-比如Word文档或者幻灯片。此时需要使用悲观锁，只能有一个签出是可写的-这就需要一个集中式的系统。分布式的工作流有两种，第一种，Partner工作流。按照Partner工作流，一个开发人员启动一个项目，然后进行分支。然后，在不同开发人员工作的分支之间来回合并更改。

第二种常用的工作流是通过本地提交使用集中式服务器。在这种工作流中，开发人员的工作方式与使用集中式 subversion 存储库时非常相似，但是他们进行本地提交，然后把最终更改推到集中式服务器。这种工作流有许多变体，包括与 Partner 工作流结合使用。我们基本是使用第二种工作流的。

集中式与分布式的对比

• 速度 - 由于没有本地仓库拷贝，Subversion较慢，尤其是当服务器远在其他大洲时。

• 连接 - 即使网络断掉，分布式VCS也能够使用。

• 分支 - 分布式VCS鼓励使用分支：
  分布式VCS鼓励为试验快速创建分支。你也可以在Subversion中创建分支，但它们对所有人可见，妨碍了大家这么做。与此类似，分布式VCS鼓励在工作中设置检查点：你可以向本地代码库签入没有完成的代码，它们可能测试不过，甚至编译不过。同样，Subversion中你也可以在开发者分支中 这样做，但由于这些分支是共享的，大家都不愿意这样做。