两种不同的代码版本管理方法

A方法：

  在每个release中，每个人都建立自己的branch，各自的代码修改都在自己的branch中。等到release前两天，才能把代码merge到trunk里。

  前提：

  1. release要足够短。如果你的release是两三个月甚至更长时间才进行一次，那merge代码时产生的问题会让你焦头烂额。

  2. 充分的测试代码，保证代码质量。

  3. merge前，merge中（代码merge了，但还没有commit）以及merge后都要进行完整测试，以保证merge不会对trunk代码的质量产生影响。

  4. 如果merge时发现conflict，需要重新进行3的后两个步骤。

  优点：

  1. 适用于需要经常性release的项目。

  2. trunk的代码总“可用” --- 即已经经过上次release时足够的项目质量检验。

  缺点：

  1. merge时，往往会有较多的conflicts。

  2. 为了不产生太多的conflicts，需要的协调工作较多。

  3. 无法预知merge之后的代码会产生的问题。

 

B方法：

  代码的修改基于最新的trunk代码，而且每个人都可以随时把代码commit到trunk里。

  前提：

  1. 要有一个经过足够质量检测的branch版本，用作production上的版本。

  2. 要有足够的测试代码保证代码的质量。

  3. 要有持续集成工具随时监测trunk上代码的质量，如果上次build失败，则不许再commit代码，直到build被修复。

  4. story要尽量小。

  优点：

  1. 符合持续集成的理念。

  2. trunk的代码始终是最新的，而且是“可用的”。

  3. 因为commit频繁，所以产生conflict的机会较小。

  缺点：

  需要维护额外的release branch版本，当需要打补丁的时候，要在两处保持同步。

 

 

  两种管理代码的方式，各有优劣，但B方法更符合敏捷理念，而且，本质上其实是一种对A方法的替代。