当您想要进行持续集成时,最好的分支策略是什么?
同时使用这两种策略有意义吗?就像在每个版本中,您的分支都是针对大型特性的吗?这些策略中的一种是否与持续集成更好地结合起来?当使用不稳定的主干时,使用持续集成是否有意义?
发布于 2009-03-03 06:28:12
答案取决于团队的规模、源代码管理的质量以及正确合并复杂更改集的能力。例如,在完全分支源代码管理(如CVS或SVN )中,合并可能很困难,使用第一个模型可能会更好,而如果使用更复杂的系统(如IBM ClearCase ),并且团队规模更大,则可以更好地使用第二个模型或两者的组合。
我个人会将特性分支模型分开,其中每个主要特性都是在一个单独的分支上开发的,任务子分支用于单个开发人员所做的每个更改。随着功能的稳定,它们会被合并到主干中,这样就可以保持稳定,并在任何时候都通过所有的回归测试。当您接近发布周期的末尾和所有特性分支合并时,您可以稳定发布系统分支,并在其上只进行稳定bug修复和必要的支持,而主干则用于下一个版本的开发,而您再次分支到新的特性分支。诸若此类。
这样,主干总是包含最新的代码,但是您设法保持它的稳定,在主要的更改和特性合并上创建稳定的标签(标记),特性分支在持续集成的情况下进行快速的开发,单个任务子分支通常可以从特性分支中刷新,以保持每个在相同特性上工作的每个人保持同步,同时不影响其他处理不同特性的团队。
同时,您在历史上拥有一组发布分支,您可以在其中为您的客户提供支持、支持和补丁,这些客户无论出于什么原因都停留在您产品的早期版本,甚至只是最新发布的版本上。与主干一样,您不需要在发布分支上设置持续的集成,它们在通过所有回归测试和其他版本质量控制时都会被仔细集成。
如果由于某种原因两个特性是相互依赖的,并且需要彼此进行更改,您可以考虑在同一个特性分支上开发这两个特性,或者要求这些特性定期地将代码的稳定部分合并到主干,然后在主干分支之间刷新从主干到交换代码的更改。或者,如果您需要将这两个特性与其他特性隔离开来,您可以创建一个公共分支,您可以将这些特性分支并用于在这些特性之间交换代码。
对于50岁以下的开发人员和源代码管理系统,如果没有稀疏的分支和适当的合并能力(如CVS或SVN ),上述模型就没有多大意义,这将使整个模型成为建立、管理和集成的噩梦。
发布于 2009-03-17 23:26:27
我发现这个话题真的很有趣,因为我非常依赖于我的日常工作。
希望你能找到有趣的链接。
发布于 2009-02-28 07:50:14
我个人认为有一个稳定的躯干和功能分支要干净得多。这样,测试人员和类似的人就可以停留在单一的“版本”上,并从主干中进行更新,以测试任何代码完成的特性。
另外,如果多个开发人员正在处理不同的特性,他们都可以拥有自己的独立分支,然后在完成后合并到主干,然后发送一个特性进行测试,而测试人员不必切换到多个分支来测试不同的特性。
作为额外的奖励,有一定程度的集成测试是自动出现的。
https://stackoverflow.com/questions/597707
复制相似问题