Behind the Code

用过一段时间的git，感觉非常之爽歪歪，但是也发现了一些问题，比如团队的成员并不是很容易的接受git，觉得麻烦。而且对于在含有*nix和windows上面同时开发的团队，经常要在不同的环境中处理回车换行的问题。这时候git不是不能解决，而是一遍一遍的给团队的成员灌输这些东西，成本是非常高的。 这两天抽空研究了一下Hg，发现国内外的“实用主义者”更倾向于使用这个。她和svn的一些使用习惯差不多，比如diff时候的版本号都是使用冒号(:)分割等等。这些小细节往往则是团队开发中选择一个工具的比较重要的因素。 我决定继续研究一段hg，然后考虑一下是否更加合适在团队中使用。

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

我们在开发过程中一般都使用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工具呢？