1、 单分支-串行开发模式
串行开发模式 称最理想的开发模式，只需要一个代码管理的配置库，一个主干（单分支）处理全部的需求开发和bug修复的工作，所有代码相关的活动都是有计划、串行的进行。
在这个开发模式下，每一次版本的提交（或者说某一个特定的项目阶段）只能实现一个目的：实现某个需求或者修复系统缺陷（bug）。已经上线运行的系统，依靠不断的版本升级来实现缺陷修复和新业务功能实现。
图 1 单分支-串行开发模式
如上图所示，Trunk是开发人员的工作集，按照项目阶段来完成相应的工作，即：新需求开发阶段不进行系统缺陷修复工作，只有在新需求的版本已经通过Tags交付上线后，再安排单独的项目阶段来进行缺陷修复、重新提交Tags并系统部署上线。Tags仅仅作为基线，用于标记版本的基线信息。
然而，理想是丰满的、现实是残酷的。一个系统上线后是需要长期维护的，随着时间的推移，修复线上bug的工作以及伴随着配合业务变化而新增的需求，将会日益增多。往往这些线上bug的修复与新需求上线无法严格遵守串行开发模式的规范要求（先开发后上线）。例如：有一个双十一的活动推广需求，业务部门严格要求在双十一前上线；这时系统有一个影响到业务的bug也需要紧急修复，但是因为修复bug的工作复杂度导致不可能在双十一前完成。因此，引入了并行开发模式。
2、 多分支-并行开发模式
正如前文中提到的问题，当串行开发模式不能适用时，开发者将自觉或不自觉地引入并行开发模式。所谓并行，也就是说配置管理的代码库中将存在多个独立且互不影响的版本，例如：生产版本、新需求的版本、缺陷bug修复的版本。
图 2 多分支-并行开发模式
在这个模式下除了引入分支（Branches）的概念，和前一个模式比，Trunk和Tag的定义也有新的变化。首先，Trunk仅仅用于新需求的发开以及上线前发现的缺陷（bug）的修复，不再涵盖生产环境缺陷的修复活动；其次，Tags只记录缺陷修复以及缺陷修复后上线版本的基线；最后，分支（Branches）一般分为三个不同的类型：生产分支、缺陷修复分支和归并分支。
生产分支不做任何的代码变动，只保证生产分支的最新代码和线上的生产环境完全一致；缺陷修复分支只处理生产环境缺陷的修复，需要与生产分支做匹配，在进行缺陷修复前必须与发现生产环境缺陷的版本做同步；归并分支是在上线发布前，合并了新需求代码、修复生产环境缺陷后的代码、对应生产分支基线（发现生产环境缺陷的基线版本）的代码版本，这个版本的代码需要进行全回归测试，测试通过后确认新的版本基线并完成生产环境部署、同时归并入生产分支（遵守生产分支管理的基本原则：保证生产分支的最新代码和线上的生产环境完全一致）。
3、 总结
单分支模式简单清晰，无须在开发过程中增加额外的分支归并或者代码冲突解决的工作，但是无法支持并行开发和多版本发布机制。多分支模式则正好相反，虽然需要专职的配置管理员对并行工作的各类分支进行版本控制的管理，但是只要版本控制管理的规划清晰，该模式是可以从根本上保证生产环境版本的稳定，规避了投产的版本风险。
4、 思考题，欢迎讨论^_^
图 2中的R-20140817-001包括哪些内容？
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！