Behind the Code

有没有遇到过这样的时候，一个手欠，或者没注意，一个还没有完全写好的功能就放到主分支上了，而且还很幸运的打到release里面。好吧，你没那么幸运，但是几个经验不是很丰富的小弟把代码随便传上来，你总得看一下吧。 这个怎么搞呢？难道你跑去每个人的地方看看？看着他们跑测试用例？跟着他们做Code Review？一两个人还行，人多呢？要是人不在你身边呢？比如远程开发？如果组织结构更大一点呢？开发团队在开发，测试团队在测试，这样很可能一个没有经过充分测试、检查过的代码版本，就被测试团队抓走了，然后可能就是一堆的问题咯。其实有问题还好，要是有问题没检查出来，那就更麻烦了。 所以，利用bzr的这种天然的DVCS的优势，添加了一个叫做Gatekeeper，看门人的概念。这个概念说起来是很简单的，就是所有的代码，该提交提交，该搞啥搞啥，但是呢，不是提交到主开发分支哪里，而是提交到看门人负责的一个分支上，由他来进行统一的测试审查等等。等完事OK了，他（只有他）再提交到主分支上就好了。这样就保证了所有的问题，低质量的代码，都被看门人挡住了。 看门人可以是一个人，也可以是一个团队，只要能够保证产品的质量就可以了。 比如在服务器，代码都是放在/repo/main上面的，哪么现在根据main生成一个dev.main的分支，所有的人都是基于dev.main进行开发。而测试团队则选择main进行测试，这样开发和测试就已经分开了。然后看门人保证dev.main的质量，当质量达到一定的水平之后，并且代码稳定了，就可以把dev.main merge到main上面了。

bzr 是一个分布式的版本控制工具，如果我们还那他当svn使用，那就有点暴敛天物了。 所以我们就得按照bzr的方式办事。 svn方式开发最大的问题就是当n个人开发不同的feature，又来回影响时候，基本上就只能使用branch了，否则就玩完了。这时候就得靠DVCS了。而对于所有的DVCS，都是天然的支持轻量级分支，或者天然的就应该按照分支进行开发。 我们可以按照如下的方法开发假设服务器是  /server/repo我们在开发的时候不是想svn一样使用checkout来创建本地工作区，而是在本地做一个服务器代码库的分支，然后进行本地开发。以bzr为例子就是bzr branch /server/repo [local_proj_name]这时候这个local_proj_name是一个服务器工作区的分支，可以进行开发了，并且所有的提交都是本地的，不会影响到服务器的工作区。 如果你和别人一起共享一个服务器的代码库，随时获取最新的代码，在svn里面是使用update，在这里是使用pull，如果出现了和本地的冲突，哪么就需要使用merge来进行合并了。等你在本地工作区都开发好了，也本地提交好了，哪么使用push在传回服务器的代码库就可以了。 这里我想说一下pull和merge的区别。pull的意思是把代码同步成为服务器代码库的代码，并且版本号也发生变化。pull操作成功后，本地就是一个提交后的状态。merge的意思是把服务器代码库的代码，合并到本地，此时仅仅是内容的变化，版本是不会发生变化的。所以merge之后，本地是一个修改后的状态，还需要提交一次，本地才是一个提交后的状态。 比如服务器代码库只有一个文件，叫做readme.txt，在版本是9的时候，readme.txt的内容是No。版本号码是10的时候，内容是Yes。 如果我本地的工作区，是从版本号码为9做的本地分支。我现在pull下来，哪么我本地readme.txt的文件的内容是Yes，本地分支版本号码是10，处于以提交状态。如果是merge下来，哪么本地readme.txt的内容是Yes，本地分支版本号码是9，处于已修改状态，需要自己提交以下，是本地的版本号码达到10。

bzr有很多种使用方法，我们首先介绍集中式的使用方法，你可以假装他就是svn。 bzr的基本语法是 bzr 命令 [参数] 首先创建一个代码仓库#bzr init-repo –no-tree ftp://user@host/repo-name这里使用了ftp作为代码仓库的中心服务器，bzr支持的协议有很多ftp，sftp,http,bzr等等，我这里使用了ftp为了方便。 命令init-repo是创建代码仓库的命令，–no-tree是说明这个代码仓库本身的物理位置是不参与开发的。 然后创建项目，更精确的说是创建一个分支#bzr init ftp://user@host/repo-name/proj1-trunk 然后checkout代码#bzr checkout ftp://user@host/repo-name/proj1-trunk proj1然后就是熟悉的场景了，可以随意的使用，折腾，捣乱，然后commit到中心代码库。其他的使用者也可以随时update获取最新的代码。怎么样，跟svn一样吧，甚至连基本的命令都一样，比如commit/ci，update/up，revert，info，state/st。 这里面要注意一个问题，就是使用init命令创建的是一个分支，一个branch。branch在bzr当中是非常重要的，如果你了解一些svn详细的东西，你会发现被管理的每一个目录都有一个叫做.svn的目录，也就是我们可以认为从任何的子目录开始都是一个完整的可以被单独checkout的小项目。而bzr则不然，他只是在每一个branch的目录下才有一个.bzr目录，也就是从这一点开始，才是branch的根，下层的任何目录都不能成为一个单独的独立结构。而这个branch是需要用init命令搞定的，不能想svn里面一样随随便便的就创建一个目录就完了。 所以从这里我们看出，bzr是完全可以按照svn的思想来使用bzr。不过，这不就没意义了，我为什么不直接用svn呢，所以我们在使用bzr的时候，还是有一些区别的，下篇再说。

我们在开发过程中一般都使用VCS工具，最普遍的工具就是svn，但是在使用过程中还是会存在一些问题的。 假设一个场景一个项目要进行开发， A是底层核心功能开发人员，他要对底层进行开发，并且在第一时间所有的人都要获取他的代码 B是功能开发人员，进行一个feature1的开发 C，D是功能开发人员，进行另外一个feature2的开发 feature1和feature2要公用部分代码，比如同一个接口文件，并对他进行修改 假如我们用svn进行开发，这里面是有一个问题的，因为A的存在，feature1和feature2的开发并不能完全分开，而在开发阶段B，C，D三个人都不能随意的提交代码，否则feature1和feature2都会相互影响。如果他们真的都是分开的功能也没问题，但是因为C，D是一个feature的负责人，他们之间必须要进行代码交换，而因为svn是集中式开发，那么他们应该，必须，也只能通过svn进行代码交换。如果 C提交代码，要求D更新代码 A提交代码，要求所有人更新代码 D获取代码，A和C的，是正确的代码 B获取代码，死菜了，因为C的代码是他不需要的，会影响他的工作，甚至都无法编译通过 这个是一个很普遍的场景，尤其是对人数多一些的小组。那么我们应该如何避免这种情况的发生呢？答案是使用DVCS系统，也就是分布式代码管理系统，例如bzr，hg等。 DVCS的出现可以方便的解决这类问题。与svn等传统VCS系统不同，DVCS并不需要一个中心服务器，每个人的开发工作区都可以认为是中心服务器。DVCS的基础是分支，每需要一个开发工作区，都是基于已有的某个开发工作区创建一个分支，然后开发，然后进行分支的代码merge。因为这种特性，DVCS的分支操作代价非常小。当然对于管理，发布等等我们还是需要一个中心服务器的，那么我们只要一个放在中心服务器的分支就足够了，使用完全相同的技术和下面的各个开发工作区进行代码交换。从技术上，他们的地位是完全等同的。根据这些，我们再使用DVCS假设一下上述的开发场景 在中心服务器创建技术开发版本 A，B，C，D分别根据中心服务器创建自己的开发分支 A进行开发，每个阶段，B，C，D基于A提供的代码进行merge，比如A自己架设一个（临时的）ftp C进行开发，每一阶段，D基于C提供的代码进行merge，相对D的开发来说，情况一样。他们的开发完全不影响B的开发 最终都开发完成，一并merge回中心服务器 这就非常顺利的避免了上面遇到的问题。而且，DVCS因为是把自己的工作区认为是代码仓库（repository），所以可以随时的提交代码，随时记录自己的开发变更。而这个在svn当中有时就比较头疼，如果一个feature要开发时间比较长，那么中间的每一个小阶段的代码就很难记录了。 当然了，你可以说，我在svn当中采用给每个人开分支的方法解决这个问题。bingo，没错，但是，这已经就是DVCS的思想了，不是么？那么为什么不用一个现成的DVCS工具呢？