当您想要进行持续集成时，最佳分支策略是什么？
Release Branching：在trunk上开发，为每个版本保留一个分支 .
特征分支：在单独的分支中开发每个特征，仅合并一次稳定 .
将这两种策略结合使用是否有意义？在，你为每个版本分支，但你也分支大型功能？这些策略中的一个是否与持续集成更好地结合？使用不稳定的 Baggage 箱时，使用持续集成是否有意义？
答案取决于团队规模和源代码控制的质量以及合并正确复杂变更集的能力 . 例如，在完整的分支源控制中，如CVS或SVN合并可能很困难，使用第一个模型可能会更好，而如果使用更复杂的系统（如IBM ClearCase）和更大规模的团队，您可能会更好地使用第二个模型模型或两者的组合 .
我个人会将功能分支模型分开，其中每个主要功能都是在一个单独的分支上开发的，每个变更都由各个开发人员完成 . 随着功能稳定，它们会合并到主干，您可以保持相当稳定并始终通过所有回归测试 . 当您接近发布周期结束并且所有功能分支合并时，您可以稳定并分支发布系统分支，在该分支上您只执行稳定性错误修复和必要的反向移植，而主干用于开发下一个发行版并再次使用分支新的功能分支 . 等等 .
这种方式trunk总是包含最新的代码，但你设法保持相当稳定，在主要变化和功能合并上创建稳定的标签（标签），功能分支是快节奏的开发，持续集成和个别任务子分支可以经常从功能分支刷新，以使每个人同步处理同一功能，同时不影响处理不同功能的其他团队 .
同时，您可以通过历史记录获得一组发布分支，您可以为您的客户提供后端，支持和错误修正，无论出于何种原因，这些客户可以使用以前版本的产品，甚至只是最新发布的版本 . 与主干一样，您不会在发布分支上设置持续集成，在通过所有回归测试和其他发布质量控制时会仔细集成它们 .
如果由于某种原因，两个功能是相互依赖的并且需要相互更改，则可以考虑在同一功能分支上开发两者，或者要求功能定期将代码的稳定部分合并到主干，然后刷新更改trunk用于在trunk分支之间交换代码 . 或者，如果您需要将这两个功能与其他功能隔离开来，则可以创建一个公共分支，您可以在该分支上分支这些功能分支，并可以使用这些分支在功能之间交换代码 .
对于没有稀疏分支和CVS或SVN等适当合并能力的50个开发人员和源控制系统的团队，上述模型没有多大意义，这将使整个模型成为设置，管理和集成的噩梦 .
我发现这个话题非常有趣，因为我在日常工作中严重依赖分支机构 .
我记得Mark Shuttleworth提出了一个关于保持主要分支原始而超越传统CI的模型 . 我贴了它here .
由于我熟悉Cruise Control，我还写了关于任务分支和CI here的博客 . 这是一个循序渐进的教程，用Plastic SCM解释如何做到这一点 .
最后，我在Duvall关于CI very interesting too的书中找到了一些关于CI的话题（可能还有关于分支的讨论） .
希望你找到有趣的链接 .
我个人觉得拥有一个稳定的 Baggage 箱并进行功能分支会更加清晰 . 这样，测试人员等就可以保持单个“版本”并从主干更新以测试任何代码完成的功能 .
此外，如果多个开发人员正在开发不同的功能，他们都可以拥有自己独立的分支，然后在完成后合并到主干，并发送要测试的功能，而测试人员不必切换到多个分支来测试不同的功能 .
作为额外的奖励，可以自动进行一定程度的集成测试 .
我认为任何策略都可以用于持续开发，前提是您记得每个开发人员每天提交到主干/主线的关键原则之一 .
http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay
编辑
我一直在阅读有关CI的this book，并且作者建议按版本分支是他们首选的分支策略 . 我必须同意 . 使用CI时按功能分支对我没有意义 .
我会试着解释为什么我这么想 . 假设三位开发人员各自参加分支处理功能 . 每项功能都需要几天或几周才能完成 . 为了确保团队不断整合，他们必须每天至少一次向主要分支机构承诺 . 一旦他们开始这样做，他们就失去了创建功能分支的好处 . 他们的更改不再与所有其他开发人员的更改分开 . 既然如此，为什么还要先创建功能分支？
在发布版本中使用分支需要在分支之间进行更少的合并（总是一件好事），确保所有更改尽快集成并且（如果正确完成）确保您的代码库始终准备好发布 . 通过发布分支的缺点是你必须更加小心改变 . 例如 . 必须逐步进行大型重构，如果您想在下一个版本中使用某种feature toggling机制，则必须隐藏它 .
另一个编辑
关于这个问题，有不止一个意见 . 这是一篇博客文章，它是支持CI的专业分支
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
如果您需要维护应用程序的多个版本，则发布分支非常有用，甚至是绝对必需的 .
功能分支也非常方便，特别是如果一个开发人员需要处理巨大的变化，而其他人仍然发布新版本 .
所以使用这两种机制对我来说是一个非常好的策略 .
有趣的链接来自Book of SVN .
我最近在使用git时喜欢this model . 虽然您的问题已标记为"svn"，但您仍可以使用它 .
在这个模型中，持续集成可以在某种程度上发生在"develop"分支（或者你称之为的任何分支）中，尽管为将来的版本提供了长时间运行的功能分支，但是我真的不希望这样 . Martin Fowler does.
持续集成不应成为决定分支策略的任何因素 . 您的分支方法应根据您的团队，正在开发的系统以及可用的工具进行选择 .
话说回来 ...
在您描述的两种方法中都使用's no reason why CI couldn'
这些方法在组合方面运作良好
两者都没有比另一个更好
CI在不稳定的 Baggage 箱中完全有意义
所有这些都在您从中获取图表的页面上的第四个问题中得到了解答：http://blogs.collab.net/subversion/2007/11/branching-strat/
只要您了解原则，您就可以随时重新发明最佳实践 . 如果您不了解原则，那么由于外部要求存在一些冲突，最佳实践将在您崩溃之前将其带走 .
有关Mainline模型的最佳介绍，请阅读：https://web.archive.org/web/20120304070315/http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
阅读链接 . 一旦掌握了基础知识，请阅读以下文章，由着名的Henrik Kniberg撰写 . 它将帮助您将Mainline Model与持续集成联系起来 .
http://www.infoq.com/articles/agile-version-control
当我们开始我们的团队时，我们继承了最初开发我们即将负责的系统的供应商的基于发布的策略 . 它一直工作到我们的客户要求不应该在发布版本中包含多个开发的功能（f.y.i.~250k代码行，~2500个文件，带有XP SDLC的Scrum） .
然后我们开始研究基于特征的分支 . 这也工作了一段时间 - 比如我们意识到我们的回归测试过程将花费超过2周的时间，直到我们意识到我们的回归测试过程将花费超过2周，结合将要发布的不确定性造成巨大的不便 .
当我们决定我们应该拥有1.稳定的主干和2. 生产环境 应该包含ST，UAT和回归测试的BINARIES（不仅仅是来源 - 想想CC）时，纯SC策略的最终“棺材中的钉子”来了 .
这导致我们设计出一种策略，它是功能和基于发布的SC策略之间的混合体 .
所以我们有一个主干 . 每个sprint都分支出sprint分支（对于非敏捷人员来说 - sprint只是一个基于复杂性的可变输出的时间盒开发工作 . ）从sprint分支我们创建功能分支并在其中开始并行开发 . 一旦功能完成并进行系统测试，我们就会收到部署它们的意图，它们会合并到sprint分支 - 有些可能会浮动几个sprint，通常是更复杂的sprint . 一旦sprint接近尾声并且功能完成......我们将sprint分支“重命名”为“回归”（这允许CruiseControl在没有任何重新配置的情况下接收它）然后在cc-built上开始回归/集成测试耳 . 当这一切都完成后，它就会投入 生产环境 .
简而言之，基于特征的分支用于开发，系统测试和UAT功能 . sprint分支（实际上是发布分支）用于有选择地按需和集成测试合并功能 .
现在这是社区的一个问题 - 我们显然无法执行持续集成，因为开发发生在许多分支上并且重新配置开销很大巡航控制 . 有人可以建议和建议吗？
我看到它的方式你想拥有一组有限的分支，你可以集中精力 . 由于您需要测试，代码质量指标以及许多与构建一起运行的有趣内容，因此报告太多可能会让您错过信息 .
分支的时间和内容通常取决于团队的规模和正在开发的功能的大小 . 我认为没有黄金法则 . 确保您使用的策略可以提前/经常获得反馈，其中包括从功能的一开始就涉及到质量 . 质量位，意味着随着团队的发展自动化，如果您为团队正在构建的大型功能集进行分支，那么您也必须具备团队的质量 .
ps你从哪里获得这些方法参考？ - 不认为这些图表代表所有选项
Update 1: 扩大我为什么说它不是黄金法则 . 基本上对于相对较小的团队，我发现最好使用混合方法 . 如果功能分支很长，则会创建功能分支，并且团队的一部分将继续添加较小的功能 .
我认为你使用的工具是一个很重要的因素 .
如果您正在使用subversion，请坚持使用选项1并从分支中释放 .
如果您使用GIT，选项2将适合您 .
11 回答
答案取决于团队规模和源代码控制的质量以及合并正确复杂变更集的能力 . 例如，在完整的分支源控制中，如CVS或SVN合并可能很困难，使用第一个模型可能会更好，而如果使用更复杂的系统（如IBM ClearCase）和更大规模的团队，您可能会更好地使用第二个模型模型或两者的组合 .
我个人会将功能分支模型分开，其中每个主要功能都是在一个单独的分支上开发的，每个变更都由各个开发人员完成 . 随着功能稳定，它们会合并到主干，您可以保持相当稳定并始终通过所有回归测试 . 当您接近发布周期结束并且所有功能分支合并时，您可以稳定并分支发布系统分支，在该分支上您只执行稳定性错误修复和必要的反向移植，而主干用于开发下一个发行版并再次使用分支新的功能分支 . 等等 .
这种方式trunk总是包含最新的代码，但你设法保持相当稳定，在主要变化和功能合并上创建稳定的标签（标签），功能分支是快节奏的开发，持续集成和个别任务子分支可以经常从功能分支刷新，以使每个人同步处理同一功能，同时不影响处理不同功能的其他团队 .
同时，您可以通过历史记录获得一组发布分支，您可以为您的客户提供后端，支持和错误修正，无论出于何种原因，这些客户可以使用以前版本的产品，甚至只是最新发布的版本 . 与主干一样，您不会在发布分支上设置持续集成，在通过所有回归测试和其他发布质量控制时会仔细集成它们 .
如果由于某种原因，两个功能是相互依赖的并且需要相互更改，则可以考虑在同一功能分支上开发两者，或者要求功能定期将代码的稳定部分合并到主干，然后刷新更改trunk用于在trunk分支之间交换代码 . 或者，如果您需要将这两个功能与其他功能隔离开来，则可以创建一个公共分支，您可以在该分支上分支这些功能分支，并可以使用这些分支在功能之间交换代码 .
对于没有稀疏分支和CVS或SVN等适当合并能力的50个开发人员和源控制系统的团队，上述模型没有多大意义，这将使整个模型成为设置，管理和集成的噩梦 .
我发现这个话题非常有趣，因为我在日常工作中严重依赖分支机构 .
我记得Mark Shuttleworth提出了一个关于保持主要分支原始而超越传统CI的模型 . 我贴了它here .
由于我熟悉Cruise Control，我还写了关于任务分支和CI here的博客 . 这是一个循序渐进的教程，用Plastic SCM解释如何做到这一点 .
最后，我在Duvall关于CI very interesting too的书中找到了一些关于CI的话题（可能还有关于分支的讨论） .
希望你找到有趣的链接 .
我个人觉得拥有一个稳定的 Baggage 箱并进行功能分支会更加清晰 . 这样，测试人员等就可以保持单个“版本”并从主干更新以测试任何代码完成的功能 .
此外，如果多个开发人员正在开发不同的功能，他们都可以拥有自己独立的分支，然后在完成后合并到主干，并发送要测试的功能，而测试人员不必切换到多个分支来测试不同的功能 .
作为额外的奖励，可以自动进行一定程度的集成测试 .
我认为任何策略都可以用于持续开发，前提是您记得每个开发人员每天提交到主干/主线的关键原则之一 .
http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay
编辑
我一直在阅读有关CI的this book，并且作者建议按版本分支是他们首选的分支策略 . 我必须同意 . 使用CI时按功能分支对我没有意义 .
我会试着解释为什么我这么想 . 假设三位开发人员各自参加分支处理功能 . 每项功能都需要几天或几周才能完成 . 为了确保团队不断整合，他们必须每天至少一次向主要分支机构承诺 . 一旦他们开始这样做，他们就失去了创建功能分支的好处 . 他们的更改不再与所有其他开发人员的更改分开 . 既然如此，为什么还要先创建功能分支？
在发布版本中使用分支需要在分支之间进行更少的合并（总是一件好事），确保所有更改尽快集成并且（如果正确完成）确保您的代码库始终准备好发布 . 通过发布分支的缺点是你必须更加小心改变 . 例如 . 必须逐步进行大型重构，如果您想在下一个版本中使用某种feature toggling机制，则必须隐藏它 .
另一个编辑
关于这个问题，有不止一个意见 . 这是一篇博客文章，它是支持CI的专业分支
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
如果您需要维护应用程序的多个版本，则发布分支非常有用，甚至是绝对必需的 .
功能分支也非常方便，特别是如果一个开发人员需要处理巨大的变化，而其他人仍然发布新版本 .
所以使用这两种机制对我来说是一个非常好的策略 .
有趣的链接来自Book of SVN .
我最近在使用git时喜欢this model . 虽然您的问题已标记为"svn"，但您仍可以使用它 .
在这个模型中，持续集成可以在某种程度上发生在"develop"分支（或者你称之为的任何分支）中，尽管为将来的版本提供了长时间运行的功能分支，但是我真的不希望这样 . Martin Fowler does.
持续集成不应成为决定分支策略的任何因素 . 您的分支方法应根据您的团队，正在开发的系统以及可用的工具进行选择 .
话说回来 ...
在您描述的两种方法中都使用's no reason why CI couldn'
这些方法在组合方面运作良好
两者都没有比另一个更好
CI在不稳定的 Baggage 箱中完全有意义
所有这些都在您从中获取图表的页面上的第四个问题中得到了解答：http://blogs.collab.net/subversion/2007/11/branching-strat/
只要您了解原则，您就可以随时重新发明最佳实践 . 如果您不了解原则，那么由于外部要求存在一些冲突，最佳实践将在您崩溃之前将其带走 .
有关Mainline模型的最佳介绍，请阅读：https://web.archive.org/web/20120304070315/http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
阅读链接 . 一旦掌握了基础知识，请阅读以下文章，由着名的Henrik Kniberg撰写 . 它将帮助您将Mainline Model与持续集成联系起来 .
http://www.infoq.com/articles/agile-version-control
当我们开始我们的团队时，我们继承了最初开发我们即将负责的系统的供应商的基于发布的策略 . 它一直工作到我们的客户要求不应该在发布版本中包含多个开发的功能（f.y.i.~250k代码行，~2500个文件，带有XP SDLC的Scrum） .
然后我们开始研究基于特征的分支 . 这也工作了一段时间 - 比如我们意识到我们的回归测试过程将花费超过2周的时间，直到我们意识到我们的回归测试过程将花费超过2周，结合将要发布的不确定性造成巨大的不便 .
当我们决定我们应该拥有1.稳定的主干和2. 生产环境 应该包含ST，UAT和回归测试的BINARIES（不仅仅是来源 - 想想CC）时，纯SC策略的最终“棺材中的钉子”来了 .
这导致我们设计出一种策略，它是功能和基于发布的SC策略之间的混合体 .
所以我们有一个主干 . 每个sprint都分支出sprint分支（对于非敏捷人员来说 - sprint只是一个基于复杂性的可变输出的时间盒开发工作 . ）从sprint分支我们创建功能分支并在其中开始并行开发 . 一旦功能完成并进行系统测试，我们就会收到部署它们的意图，它们会合并到sprint分支 - 有些可能会浮动几个sprint，通常是更复杂的sprint . 一旦sprint接近尾声并且功能完成......我们将sprint分支“重命名”为“回归”（这允许CruiseControl在没有任何重新配置的情况下接收它）然后在cc-built上开始回归/集成测试耳 . 当这一切都完成后，它就会投入 生产环境 .
简而言之，基于特征的分支用于开发，系统测试和UAT功能 . sprint分支（实际上是发布分支）用于有选择地按需和集成测试合并功能 .
现在这是社区的一个问题 - 我们显然无法执行持续集成，因为开发发生在许多分支上并且重新配置开销很大巡航控制 . 有人可以建议和建议吗？
我看到它的方式你想拥有一组有限的分支，你可以集中精力 . 由于您需要测试，代码质量指标以及许多与构建一起运行的有趣内容，因此报告太多可能会让您错过信息 .
分支的时间和内容通常取决于团队的规模和正在开发的功能的大小 . 我认为没有黄金法则 . 确保您使用的策略可以提前/经常获得反馈，其中包括从功能的一开始就涉及到质量 . 质量位，意味着随着团队的发展自动化，如果您为团队正在构建的大型功能集进行分支，那么您也必须具备团队的质量 .
ps你从哪里获得这些方法参考？ - 不认为这些图表代表所有选项
Update 1: 扩大我为什么说它不是黄金法则 . 基本上对于相对较小的团队，我发现最好使用混合方法 . 如果功能分支很长，则会创建功能分支，并且团队的一部分将继续添加较小的功能 .
我认为你使用的工具是一个很重要的因素 .
如果您正在使用subversion，请坚持使用选项1并从分支中释放 .
如果您使用GIT，选项2将适合您 .