首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >进行连续集成时的最佳分支策略?

进行连续集成时的最佳分支策略?
EN

Stack Overflow用户
提问于 2009-02-28 07:44:15
回答 12查看 63.6K关注 0票数 104

当您想要进行持续集成时,最好的分支策略是什么?

  1. 发布分支:在主干上开发,为每个版本保留一个分支。
  2. 特性分支:在一个单独的分支中开发每个特性,只合并一次稳定。

同时使用这两种策略有意义吗?就像在每个版本中,您的分支都是针对大型特性的吗?这些策略中的一种是否与持续集成更好地结合起来?当使用不稳定的主干时,使用持续集成是否有意义?

EN

回答 12

Stack Overflow用户

发布于 2009-03-03 06:28:12

答案取决于团队的规模、源代码管理的质量以及正确合并复杂更改集的能力。例如,在完全分支源代码管理(如CVS或SVN )中,合并可能很困难,使用第一个模型可能会更好,而如果使用更复杂的系统(如IBM ClearCase ),并且团队规模更大,则可以更好地使用第二个模型或两者的组合。

我个人会将特性分支模型分开,其中每个主要特性都是在一个单独的分支上开发的,任务子分支用于单个开发人员所做的每个更改。随着功能的稳定,它们会被合并到主干中,这样就可以保持稳定,并在任何时候都通过所有的回归测试。当您接近发布周期的末尾和所有特性分支合并时,您可以稳定发布系统分支,并在其上只进行稳定bug修复和必要的支持,而主干则用于下一个版本的开发,而您再次分支到新的特性分支。诸若此类。

这样,主干总是包含最新的代码,但是您设法保持它的稳定,在主要的更改和特性合并上创建稳定的标签(标记),特性分支在持续集成的情况下进行快速的开发,单个任务子分支通常可以从特性分支中刷新,以保持每个在相同特性上工作的每个人保持同步,同时不影响其他处理不同特性的团队。

同时,您在历史上拥有一组发布分支,您可以在其中为您的客户提供支持、支持和补丁,这些客户无论出于什么原因都停留在您产品的早期版本,甚至只是最新发布的版本上。与主干一样,您不需要在发布分支上设置持续的集成,它们在通过所有回归测试和其他版本质量控制时都会被仔细集成。

如果由于某种原因两个特性是相互依赖的,并且需要彼此进行更改,您可以考虑在同一个特性分支上开发这两个特性,或者要求这些特性定期地将代码的稳定部分合并到主干,然后在主干分支之间刷新从主干到交换代码的更改。或者,如果您需要将这两个特性与其他特性隔离开来,您可以创建一个公共分支,您可以将这些特性分支并用于在这些特性之间交换代码。

对于50岁以下的开发人员和源代码管理系统,如果没有稀疏的分支和适当的合并能力(如CVS或SVN ),上述模型就没有多大意义,这将使整个模型成为建立、管理和集成的噩梦。

票数 21
EN

Stack Overflow用户

发布于 2009-03-17 23:26:27

我发现这个话题真的很有趣,因为我非常依赖于我的日常工作。

  • 我记得提出了一个关于在超越传统CI的同时保持主要分支的原始的模型。我贴了关于它的这里
  • 因为我熟悉Control,所以我还在博客上写了一些关于任务分支和CI 这里的文章。这是一个循序渐进的教程,说明如何使用塑料SCM进行操作。
  • 最后,我在Duvall关于CI 也很有趣的书中找到了一些关于CI的主题(还有可能讨论分支)。

希望你能找到有趣的链接。

票数 21
EN

Stack Overflow用户

发布于 2009-02-28 07:50:14

我个人认为有一个稳定的躯干和功能分支要干净得多。这样,测试人员和类似的人就可以停留在单一的“版本”上,并从主干中进行更新,以测试任何代码完成的特性。

另外,如果多个开发人员正在处理不同的特性,他们都可以拥有自己的独立分支,然后在完成后合并到主干,然后发送一个特性进行测试,而测试人员不必切换到多个分支来测试不同的特性。

作为额外的奖励,有一定程度的集成测试是自动出现的。

票数 9
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/597707

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档