分支和合并策略

Question

我的任务是在未来6个月内提出分支,合并和发布的策略.

复杂性来自于我们将运行多个项目,所有项目都具有不同的代码更改和不同的发布日期,但大致相同的开发日期.

目前我们正在使用VSS进行代码管理,但是我们知道它可能会导致一些问题,并且会在新开发之前迁移到TFS.

在制定计划之前,我应该采用什么策略以及应该考虑哪些事项？

对不起,如果这是模糊的,请随时提出问题,如有需要,我会更新更多信息.

Answer 1

这是我遇到过的最好的源控制模式.它强调了使行李箱不受任何垃圾(行李箱中没有垃圾)的重要性.开发应该在开发分支中进行,并且定期合并(在代码测试之后)应该被回到主干(图1),但是该模型还允许在仍在开发中修补源(图2).我绝对建议完整阅读这篇文章,以便完全理解.

     Pic 1

     Pic 2

编辑:图片肯定是没有文字的混乱.我可以解释,但我基本上会复制原作者.话虽如此,我可能应该选择更好的图片来描述合并过程,所以希望这会有所帮助.不过我仍然建议阅读这篇文章:

Answer 2

我看到分支工作的最简单和最常用的方法是两个前提.主干和发布.我认为这被称为"不稳定主干,稳定分支"的理念.

树干是您的主要来源.它包含"最新和最好的"代码,并且具有前瞻性.它通常并不总是稳定的.

Release是与trunk的一对多关联.有一个主干但很多版本都来自主干.发布一般先从躯干一旦特定功能的里程碑已经创下了分公司,使"唯一"的东西向左走在一个特定的部署应该只是bug修复.然后分支主干,给它一个标签(例如1.6 Release是我们当前的最新版本),构建并发布给QA.我们还在此时推送主干的版本号(通常是次要号码)以确保我们没有两个具有相同编号的版本.

然后,在发布分支上开始测试周期.在进行了足够的测试后,您将错误修复应用于发布分支,将这些修复合并回主干(以确保错误修复继续进行!)然后重新发布分支的构建.这个QA循环一直持续到你们都满意为止,最终发布给客户.来自客户的任何错误报告都是准确的(即它们是一个错误!)与相关分支开始另一个QA循环.

当你创造未来的版本中它是一个好主意,也尝试着旧的用户过渡到新的分支机构,以减少分支的潜在数量可能必须回修补bug修复之中.

使用此技术,您可以使用您的技术将解决方案部署到需要不同服务级别的各种客户(从最少开始),您可以将现有部署与中继中的"危险"新代码隔离,最糟糕的合并方案是一个科.