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方法的替代。