锁定老帖子 主题:两种不同的代码版本管理方法
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-05-29
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方法的替代。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-05-29
这只不过是重点不同。。。我还是以为工具带来的差别。现在版本控制工具可分为集中式和分布式。cvs ,subversion都是前者的代表。
|
|
返回顶楼 | |
发表时间:2008-05-30
说B方法更加符合敏捷,我看未必。
|
|
返回顶楼 | |
发表时间:2008-05-30
ozzzzzz 写道 说B方法更加符合敏捷,我看未必。
能否请你深入地谈谈你倾向于哪种方法?如果两种都不能符合你们团队的要求,能否说说你们是怎么管理的? |
|
返回顶楼 | |
浏览 5070 次