【每天5分钟，了解一个知识点】
分支模式的选择至关重要。不同的分支模式适用于不同的项目特点和团队习惯。让我们一起来深入了解各种分支模式，为你的项目找到最佳策略。
一、常见分支模式
（一）“三驾马车”分支模式
“三驾马车”分支模式指软件开发团队仅维护三个分支，即开发分支、预发布分支和发布分支。比如在 2010 年，Chrome 浏览器就采用这种模式。
开发分支：这是所有开发人员提交代码的目标分支。当有足够多新功能或接近发布日时，将准备发布的功能“挑拣”到预发布分支。
预发布分支：只做缺陷修复、文档生成和发布相关工作，不做新功能开发。会先发布 Alpha 版本给极少用户体验，接着发布 Beta 版本让尝鲜用户找问题，当代码稳定后，合入发布分支并发布 RC 版本。如果质量稳定，就可正式发布。
（二）Gitflow 分支模式
Gitflow 分支模式是很多企业应用的模式。
Master 分支：正式版本的发布分支。
Release 分支：预发布分支，用于质量打磨。达标后合入 Master 分支和 Development 分支。
Development 分支：集成新功能的分支。
Feature 分支：开发人员为某一功能从 Development 分支拉出，完成后合入 Development 分支。
Hotfix 分支：已发布版本出现严重缺陷时，从 Master 分支的对应版本标签处拉出，修复后合入 Master 分支并发布补丁版本，同时也要移植到 Development 分支修复缺陷。
Gitflow 分支模式是特性分支模式和“三驾马车”分支模式的组合，优点是分支定义明确清晰，但分支较多也有不足。
（三）GitHubFlow 分支模式
源于 GitHub 团队实践，对开发纪律和质量保障手段要求高。
开发人员从 Master 上创建以特性或缺陷编号命名的新分支，提交代码。
功能完成且自测通过后创建 Pull Request（PR）。
其他开发人员审查合格后合入 Master。如果特性分支存在时间短，可认为是高频的“主干开发，主干发布模式”。
二、开发分支模式选择
分支策略与版本发布周期有一定相关性。软件开发周期极长的“项目制”团队和发布频率极高的“城际快线式”团队常采用“主干开发，主干发布”策略；次之的团队用“主干开发，分支发布”；再其他的用“分支开发、主干发布”。但这不是绝对的，会受团队人数、产品架构和质量保障基础设施状况影响。
项目制发布模式不会消失，很多传统 IT 企业仍在用。城际快线模式是敏捷提倡的，越来越多企业开始采用，即使发布周期长的企业也会在项目中加入固定时间迭代，要求每个迭代有可交付状态的产品（能正常运行且特性达发布质量标准，非商业化发布）。
一般来说，发布周期缩短到一定程度后，主干开发模式更有优势，因为分支开发模式的合并成本会阻碍短周期发布。如果发布周期短于两周，团队应毫不犹豫转向“主干开发模式”。
三、总结
每种分支策略都有优缺点，对发布频率和效率影响较大。目前趋势是发布频率越来越高，周期越来越短。硅谷顶级互联网公司多采用“主干开发”或高频的 GitHubFlow 分支模式。但企业选择分支策略要根据具体情况，若配套条件不足，盲目提高发布频率和缩短周期会造成损失。
我们提倡选择分支模式的原则有：
分支越少越好，最好只有一条主干。
分支生存周期越短越好，最好在 3 天以内。
在业务允许前提下，发布周期越短越好。
【关联阅读】
关注公众号，回复【Java面试】，获取更多面试资料
