当您想要进行持续集成时,最佳分支策略是什么？
Release Branching:在trunk上开发,为每个版本保留一个分支.
特征分支:在单独的分支中开发每个特征,仅合并一次稳定.
将这两种策略结合使用是否有意义？在,你为每个版本分支,但你也分支大型功能？这些策略中的一个是否与持续集成更好地结合？使用不稳定的行李箱时,使用持续集成是否有意义？
我发现这个话题非常有趣,因为我在日常工作中严重依赖分支机构.
我记得马克·沙特尔沃思(Mark Shuttleworth)提出了一个关于保持主要分支原始而超越传统CI的模型.我在这里发布了它.
由于我熟悉Cruise Control,我还在这里写了关于任务分支和CI的博客.这是一个循序渐进的教程,解释了如何使用Plastic SCM.
最后,我在Duvall关于CI的书中发现了一些关于CI的主题(并且可能谈论分支)也非常有趣.
希望你找到有趣的链接.
答案取决于团队规模和源代码控制的质量以及合并正确复杂变更集的能力.例如,在完整的分支源控制中,如CVS或SVN合并可能很困难,使用第一个模型可能会更好,而如果使用更复杂的系统(如IBM ClearCase)和更大规模的团队,您可能会更好地使用第二个模型模型或两者的组合.
我个人会将功能分支模型分开,其中每个主要功能都是在一个单独的分支上开发的,每个变更都由各个开发人员完成.随着功能稳定,它们会合并到主干,您可以保持相当稳定并始终通过所有回归测试.当您接近发布周期结束并且所有功能分支合并时,您可以稳定并分支发布系统分支,在该分支上您只执行稳定性错误修复和必要的反向移植,而主干用于开发下一个版本,您再次使用分支新的功能分支.等等.
这种方式trunk总是包含最新的代码,但你设法保持相当稳定,在主要变化和功能合并上创建稳定的标签(标签),功能分支是快节奏的开发,持续集成和个别任务子分支可以经常从功能分支刷新,以使每个人同步处理同一功能,同时不影响处理不同功能的其他团队.
同时,您可以通过历史记录获得一组发布分支,您可以在其中为您的客户提供后端,支持和错误修正,无论出于何种原因,这些客户都可以使用以前版本的产品,甚至只是最新发布的版本.与主干一样,您不会在发布分支上设置持续集成,它们在通过所有回归测试和其他发布质量控制时会仔细集成.
如果由于某种原因,两个功能是相互依赖的并且需要相互更改,则可以考虑在同一功能分支上开发或要求功能定期将代码的稳定部分合并到主干,然后刷新更改trunk用于在trunk分支之间交换代码.或者,如果您需要将这两个功能与其他功能隔离开来,则可以创建一个公共分支,您可以在该分支上分支这些功能分支,并可以使用这些分支在功能之间交换代码.
对于没有稀疏分支和CVS或SVN等适当合并能力的50个开发人员和源控制系统的团队,上述模型没有多大意义,这将使整个模型成为设置,管理和集成的噩梦.
我个人觉得拥有一个稳定的行李箱并进行功能分支会更加清晰.这样,测试人员等可以保持单个"版本"并从主干更新以测试任何代码完成的功能.
此外,如果多个开发人员正在开发不同的功能,他们都可以拥有自己独立的分支,然后在完成后合并到主干,并发送要测试的功能,而测试人员不必切换到多个分支来测试不同的功能.
作为一个额外的好处,有一些自动化的集成测试.
如果您需要维护应用程序的多个版本,则发布分支非常有用,甚至是绝对必需的.
功能分支也非常方便,特别是如果一个开发人员需要处理巨大的变化,而其他人仍然发布新版本.
所以使用这两种机制对我来说是一个非常好的策略.
来自SVN书的有趣链接.
我认为只要你记住每个开发人员每天提交给trunk/mainline的关键原则之一,任何策略都可以用于持续开发.
http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay
编辑
我一直在读这本关于CI的书,作者建议按发布分支是他们首选的分支策略.我必须同意.使用CI时,按功能分支对我没有意义.
我会试着解释为什么我这么想.假设有三个开发人员分别负责某个功能.每项功能都需要几天或几周才能完成.为确保团队不断整合,他们必须每天至少一次向主要分支机构投入使用.一旦他们开始这样做,他们就失去了创建功能分支的好处.他们的更改不再与所有其他开发人员的更改分开.既然如此,为什么还要先创建功能分支呢？
通过发布使用分支需要更少的分支之间的合并(总是一件好事),确保所有更改尽快集成并且(如果正确完成)确保您的代码库始终准备好发布.通过发布分支的缺点是你必须更加小心改变.例如,必须逐步完成大型重构,如果您已经集成了下一版本中不需要的新功能,则必须使用某种特征切换机制隐藏它.
另一个编辑
关于这个问题有不止一个意见.这是一篇博客文章,它是支持CI的专业分支
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
京公网安备 11010802040832号 | 京ICP备19059560号-6 
