Workflows of SCM

版本控制的概念从最初的手工加版本号(比如，为旧的文件加上 .orig 后缀)以及 RCS 开始，主要体现于各自本地进行版本控制。到后来 CVS 模式流行起来，出现了中央仓库的概念。而今天大行其道的分布式版本控制系统，似乎又把主角带回了各自的本地主机那里。然而于以往各自独立的主机不一样，作为各个分布式节点的主机，在相互独立的同时，又互相有紧密的联系，甚至会出现一个特别重要的节点，充当一个“伪中央仓库”的角色。

我在 Git and Subversion 这篇 Blog 里面曾经比较过 Git 和 Subversion 各自的优缺点。这里我列举一下现在存在的几个流行的版本控制的工作模式(资料来源于 bazaar 的文档，也就是说 bazaar 同时支持一下的所有工作方式)。

中央仓库模式

这就是 CVS 和 Subversion 所使用的模式。有一个单一的中央仓库，所有人从同一个仓库取出代码，并把自己的代码提交到那里。

中央仓库 + 本地提交

正如我在 Git and Subversion 中提到过的那样，中央仓库模式的一个缺点就是你的提交会影响到别人的工作，如果你提交了一些不能工作的代码，你的同伴也许会很恼火。但是有时候一些复杂的工作不能一次完成，在 CVS 或者 Subversion 里面常见的解决办法是新开一个 branch ，在那里进行你的工作，完成之后再 merge 回来。不过这样的办法对于小模块来说确实太复杂了，相比起来，本地提交是一种更轻量级的解决方案(可惜 CVS 和 Subversion 都不支持本地提交)。

分布式仓库 + 主仓库

这有些类似于前一种模式，只是侧重点不一样。前一种模式中主要是直接提交到中央仓库，在特定的时候才使用本地提交；而这种模式则主要是在自己本地的仓库里进行开发，当一个模块功能完成以后才网主仓库里面 merge 。

分布式仓库 + gatekeeper

这种模式下各个开发人员没有直接提交到主仓库的权限，gatekeeper 负责追踪各个开发人员(或者模块，甚至是下一级的比较小的一个 gatekeeper)的状态，并在合适的时候主动从他们那里 pull 。gatekeeper 可以自己充当主仓库的角色，或者另外有一个只有 gatekeeper 才能提交的主仓库，gatekeeper 在把 pull 过来的代码 review 并通过测试以后再加入到主仓库中。Linux 内核就是采用的这种方式，内核的各个子系统在完成一个开发阶段之后，便会通知 Linus ，他的代码仓库充当内核的主仓库(事实上，这并不是通过什么机制来强制规定的，从本质上来看，他的仓库和其他开发人员的仓库是同等地位的，只是人们都信任他，把他的仓库当做 Linux Kernel 的“官方仓库”而已)，他将 pull 过来的代码 review 之后 merge 到自己的仓库之中。

这么多种管理模式？哪种适合你的项目呢？如果你所在的项目正在使用一种错误的让你感到相当痛苦的管理模式，那么不妨试试说服你的 Manager 让他变通一下。