进行持续集成时最佳的分支策略？
当你想要进行持续集成时，什么是最好的分支策略？
- 释放分支：在树干上开发，为每个版本保留一个分支。
- function分支：在单独的分支中开发每个function，只有合并一次才能稳定。
同时使用这两种策略是否合理？ 如在你分支每个版本，但你也支持大function？ 这些策略之一是否与持续集成更好地匹配？ 如果使用不稳定的中继线，使用持续整合更有意义吗？
答案取决于您的团队的规模和源控制的质量，以及正确合并复杂变更集的能力。 举例来说，像CVS或SVN这样的完全分支源代码控制可能会很困难，而使用第一个模型可能会更好，而如果使用像IBM ClearCase这样更复杂的系统，而更大的团队则可以更好地使用第二个模型模型或两者的组合。
我个人会将每个主要特性在单独的分支上开发的特性分支模型与每个开发人员所做的每个更改的任务子分支分开。 随着特征的稳定，它们将被合并到树干中，从而保持合理的稳定性并随时通过所有的回归testing。 当您接近发布周期结束并且所有function分支合并时，您稳定并分支了一个发布系统分支，在这个分支上，您只进行稳定性错误修复和必要的backports，而主干用于开发下一个发行版，并且再次为新的function分支分支。 等等。
这种方式总是包含最新的代码，但是你保持合理的稳定性，在重要的变化和特征合并上创build稳定的标签（标签），特征分支是快速发展的，持续集成和个别任务子分支可以经常从function分支刷新，以保持每个人在同一function上工作，同时不影响其他团队的不同function。
同时，您还可以通过历史logging获得一组发布分支，您可以为您的客户提供后期支持和错误修正，无论出于何种原因，您都可以继续使用以前版本的产品，甚至是最新发布的版本。 与主干一样，您不会在发布分支上设置持续集成，在通过所有回归testing和其他发布质量控制时，都会仔细整合。
如果由于某些原因，两个特性是相互依赖的并且需要彼此完成更改，则可以考虑在同一个特性分支上开发这两个特性，或者要求这些特性定期将代码的稳定部分合并到trunk中，然后从主干交换主干分支之间的代码。 或者，如果您需要将这两个function与其他function隔离开来，则可以创build一个通用分支，用于分支这些function分支，并可以使用这些分支在function之间交换代码。
上述模型对于50岁以下开发者和源代码pipe理系统的团队没有太多的意义，没有稀疏的分支和适当的合并能力，比如CVS或者SVN，这只会让整个模型成为设置，pipe理和集成的噩梦。
我觉得这个话题真的很有趣，因为我在日常工作中严重依赖分支机构。
- 我记得马克·沙特尔沃思（Mark Shuttleworth）提出了一个关于保持主要分支不变的模式，同时超越了传统的CI。 我在这里发布。
- 由于我对Cruise Control很熟悉，所以我也在这里写了关于任务分支和CI的信息 。 这是一步一步的教程解释如何用塑料SCM做到这一点。
- 最后，我发现Duvall关于CI的一些关于CI的话题（可能谈论分支） 也非常有趣 。
希望你find有趣的链接。
我个人觉得有一个稳定的树干和function分支更干净。 这样，testing人员等就可以继续使用一个“版本”，并从主干进行更新，以testing任何代码完整的function。
同样，如果多个开发人员正在开发不同的function，他们都可以拥有自己独立的分支，然后在完成后合并到主干，并发送要testing的function，而无需testing人员切换到多个分支以testing不同的function。
作为额外的好处，还有一定程度的自动化集成testing。
我想任何一种战略都可以用于持续发展，只要你记住每个开发者每天都要干的主要原则之一。
http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay
编辑
我一直在阅读关于CI的这本书 ，作者提出，通过发布分支是他们偏好的分支策略。 我必须同意。 使用CI时，按function分支对我来说毫无意义。
我会试着解释为什么我这样想。 假设三名开发人员分别从一个分支开始工作。 每个function将需要几天或几周才能完成。 为确保团队不断整合，他们必须每天至less向主要部门投入一次。 一旦他们开始这样做，他们就失去了创build一个function分支的好处。 他们的更改不再与其他开发人员的更改分开。 既然如此，为什么还要在第一时间创buildfunction分支呢？
使用按版本分支需要更less的分支之间的合并（总是一件好事），确保所有更改尽快集成（如果正确完成），确保您的代码基准始终准备好发布。 释放分支的一面是，你必须更加小心的变化。 例如，大型重构必须逐步完成，如果您已经在下一个版本中集成了一个您不想要的新特性，那么它必须使用某种特性切换机制来隐藏。
另一个编辑
关于这个问题有不止一个意见。 这是一个博客文章，这是一个function与CI分支function
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
发布分支是非常有用的，甚至绝对需要，如果你需要维护几个版本的应用程序。
function分支也非常方便，特别是如果一个开发人员需要进行巨大的改变，而其他开发人员仍然会发布新的版本。
所以对我来说，使用这两种机制是一个非常好的策略。
来自SVN之书的有趣链接。
我最近来使用git时喜欢这个模型 。 虽然你的问题被标记为“svn”，你仍然可以使用它。
在这个模型中，持续集成可以在一定程度上发生在“开发”分支（或者你所说的任何东西），但是对于将来的版本来说，长期运行的特性分支不会使它变得如此僵化，以至于不得不考虑每一个变化发生在代码的某个地方。 问题依然存在，你是否真的想要。 马丁福勒呢。
持续集成不应该成为决定分支策略的一个因素。 您的分支方法应根据您的团队，正在开发的系统和可用的工具进行select。
话说回来 …
- 为什么CI不能用于你描述的两种方法
- 这些方法组合起来效果很好
- 两者中的任何一个都不比另一个“更好”
- CI总是有一个不稳定的主干
所有这些都是在第四个问题的答案中，你从这个图上看到的： http : //blogs.collab.net/subversion/2007/11/branching-strat/
只要你明白原则，你总是可以重新发明最佳实践。 如果你不了解原则，最好的做法会在你离开之前，由于一些相互冲突的外部要求而离你很远。
要获得主线模型的最佳介绍，请阅读以下内容： https ：//web.archive.org/web/20120304070315/http： //oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
阅读链接。 一旦你了解了基础知识，请阅读Henrik Kniberg的以下文章。 它将帮助您将主线模型与持续集成联系起来。
当我们开始我们的团队时，我们从最初开发我们将要负责的系统的供应商那里inheritance了一个基于版本的策略。 直到我们的客户要求几个开发的function不应该包含在一个发行版（fyi〜250k行代码，〜2500个文件，Scrum与XP SDLC）之前，它一直在运行。
然后我们开始研究基于特征的分支。 这也工作了一段时间 – 比如2个月，直到我们意识到我们的回归testing过程将花费2周以上，结合所释放的不确定性会造成巨大的不便。
当我们决定我们应该有1稳定的树干和2生产应该包含ST，UAT和回归testing二进制文件（不只是来源 – 认为CC），纯SC战略的最后的“棺材钉”来了。
这导致我们制定了一个策略，这是一个混合function和基于发布的SC战略。
所以我们有一个主干。 每一个sprint我们分支出sprint分支（对于非敏捷的人 – sprint只是一个基于复杂性的可变输出的时间框架的开发工作）。从sprint分支中，我们创build了特性分支并开始并行开发。 一旦function完成并进行系统testing，并且我们收到了部署它们的意图，它们将被合并到sprint分支中 – 有些可能会跨越几个sprint，通常是更复杂的sprint。 一旦冲刺接近结束，特征完成…我们将冲刺分支“重命名”为“回归”（这使得CruiseControl无需重新configuration即可完成），然后对cc-built进行回归/集成testing耳。 当这一切都完成后，它将投入生产。
简而言之，基于function的分支机构用于开发，系统testing和UATfunction。 sprint分支（真正的发行分支）用于select性地合并按需和集成testingfunction。
现在这是对社区的一个问题 – 由于许多分支的发展以及CruiseControl的重新configuration开销，我们显然无法执行持续集成。 有人可以build议和build议吗？
我看到它的方式，你想有一个有限的分支，你可以专注。 既然你想testing，代码质量指标，以及许多有趣的事情与生成运行，有太多的报告可能会让你错过信息。
何时以及如何分支，通常取决于团队的规模以及正在开发的function的规模。 我不认为有一个金科玉律。 确保您使用的策略可以在早期/经常获得反馈，包括从function一开始就具有质量。 质量的好坏，意味着随着团队的发展自动化，如果您为一个团队正在build立的大型特性分支，那么您的团队中也必须具备高质量的素质。
ps你从哪里得到这些方法的参考？ – 不觉得这些图表代表所有的选项
更新1：扩展为什么我说这不是一个黄金法则。 基本上，对于相对较小的团队，我发现最好的方法是混合使用。 特征分支是如果长时间创build的，部分团队将继续添加更小的特征。
我认为你使用的工具是一个很大的因素。
- 如果你使用的是颠覆，坚持select1，并从分支释放。
- 如果你正在使用GIT，选项2将适合你。
