更多的特性分支意味着更少的持续集成

很多团队现在都默默地放弃了持续集成，原因是进行特性分支更容易，基于主干的开发欠升值， Steve Smith 说。在 Agile Tour London 2015 上，他将讨论持续集成的死亡。

InfoQ 采访了 Steve Smith，关于不同分支的方法，以及他们如何与持续集成相结合，还有为什么构建功能分支会妨碍持续集成和持续交付。

InfoQ：您能简要介绍一些正在使用的不同的分支方法吗？

Steve Smith：当然。在过去的一年里，我已经写了一系列文章，关于一些不同的版本控制策略，所有的我已经在我的职业生涯中使用过。我想评估历史背景建立不同风格分支的一种分类方法，评估其与持续集成的兼容性 - 并回答一个同事的问题：“我构造功能分支如此成功，为什么还要基于主干进行开发？“

在 20 世纪 90 年代，长生命周期的发布功能分支（ Release Feature Branching ）以及如 ClearCase，Perforce 和 MKS 工具很普遍。开发者在共享功能分支上进行几个星期，几个月，甚至可能数年的开发，并在发布产品前测试分支。之后会有一个痛苦的，耗时的合并到主干以及回归测试的过程。我曾在一个公司里使用 MKS 做过两年的发布功能分支开发，我不建议这样做。

从 21 世纪初开始基于干线的开发已开始使用诸如Subversion 和Perforce 的工具。开发者在主干上工作，每天少量增量多次提交。在主干上进行测试，用主干或者短期存在的分支进行发布。并行功能开发在使用如 Feature Toggles 和 Branch By Abstraction 的工具下完成，支持用户首选项，运行时配置。在基于主干开发上，我在三个不同公司里工作了 7 年，使用 Subversion，Mercurial，和 Git，我强烈地给所有人推荐 - 同事，家人，朋友，甚至大街上的陌生人。

在 2000 年代中期分布式版本控制系统（DVCS）成为主流，而基于主干开发也同样适用于 VCS 和 DVCS。在 DVCS 里创建分支成本更低，导致出现更加轻便功能分支策略。一个变种叫集成功能分支，跟如Git 和Mercurial 这些工具一起使用。开发人员在私人分支上进行一天的开发， 然后合并到一个长生命周期的集成分支进行测试，之后集成分支将并入主干，或在并主干前并入 Git Flow 功能发布分支。我使用 Git Flow 做了 6 个月集成功能分支开发，并不推荐它。

最后，由于 2000 年代后期编译功能分支横空出世，由于Git，Mercurial，特别是 GitHub Flow 。开发者在个人功能分支进行一天的工作之后合并到主干，用于测试和产品发布。我使用 GitHub Flow 在编译功能分支上进行了为期一年的开发，我推荐它 - 尽管很谨慎。

InfoQ：你能否详细说明这些不同的分支方法将如何与持续集成相结合？

Steve Smith：首先，持续集成不是一个工具 - 它是一种实践，团队的每一个成员提交到主干，一天至少一次，可由编译服务器如 Jenkins 或 TeamCity 验证。因此，我们可以评估一个版本控制策略，基于它能够方便进行日常提交，到主干中（叫 Master 也可以）。首先，发布功能分支和集成功能分支都与持续集成明显不兼容，因为前者在共享分支上经历了数月的开发，后者在之前的主干上包含过多的分支。

基于主干开发是持续集成的代名词，并有很好的理由 - 当每一个团队成员每天数次提交到主干，持续集成就实现了。也有其他优点，如推动团队成员分解代码库，成为一个较小的，模块化的演化架构，功能切换为使用 Canary Release 和 Dark Launching 。

编译功能分支是非常有趣的。表面看，私人功能分支审查后合并到主干，似乎与持续集成兼容，但左思右想，我得出的结论是编译功能分支可能与持续集成不兼容 - 由于开发者更多的修改，功能分支最终会被超过一天，由于开发商的工作量审查需要一天以上，而因为开发人员以异步方式进行主干合并和编译，编译变得更慢更破碎。

InfoQ：你会在 Agile Tour London 上谈“持续集成之死”，为什么？

Steve Smith：在 2014 年的#IsTDDDead 辩论，我环顾我的团队，看到大家都在利用 GitHub Flow 练习测试驱动开发，“测试驱动开发生命力旺盛，但持续集成是真正的麻烦”。

编译功能分支现在惊人流行，我猜想是由于 a）Git 和 GitHub 是好工具和 b）企业为了创意和灵感越来越多地转向了开源社区。在 Stack Overflow 2015 survey 上指出，16694 名开发者中有 11519 人（69%）在使用 Git 作为他们的源代码管理工具。2015 年七月的 Git Press 报告说有 1000 万用户和 2600 万个版本库。现在，Git 是一个非常好的工具，GitHub 同样也是。但是，持续集成是惊人重要 - 这是持续交付的基础 - 我相信很多团队将很难实现长期的，可持续的持续交付程序，如果他们盲目地采用编译功能分支的话。

InfoQ：您能分享一些资源让 InfoQ 的读者可以用它来了解更多关于分支和持续集成吗？

Steve Smith：关于持续集成的信息，我建议 Martin Fowler 的持续集成的原创文章和James Shore 和Shane Warden 的敏捷开发的艺术。有关分支模型和源代码管理， Paul Hammant 的博客是信息的重要来源。

InfoQ 将覆盖 Agile Tour London 2015 的新闻，Q＆As 和文章：

第三届 Agile Tour London 将 2015 年 10 月 23 日星期五举行，将为所有对敏捷开发感兴趣的人开放：从敏捷新手到敏捷实践者。

查看英文原文： More Feature Branching Means Less Continuous Integration

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。