版本管理(4)-|版本管理(4)- 简单清晰的分支策略有助于开发版本管理(4)-简单清晰的分支策

分支策略或者分支模型，又是一个老大难的问题。一想起来很多新手都想说：“头疼。。。别惹我”

讲分支模型之前先提一个关公战秦琼的问题（本问题来自于微博）

搞研发管理和做系统架构哪个容易？

分支模型
分支模型大致分为两类

主干开发，分支发布
所有开发活动或者说主要的开发活动都发生在主干上，每次要发布软件的时候拉取一个新的分支用来做发布分支。
分支开发，主干发布
所有开发或者说主要的开发活动都发生在大大小小的分支上，开发完成后需要合并回主干。每次需要发布时取主干上相应的版本或者标签即可。

下面我会详细说说两者的异同。
主干开发、分支发布工作方式所有开发活动或者说主要的开发活动都发生在主干上，每次要发布软件的时候拉取一个新的分支用来做发布分支。分支上的缺陷修复代码需要及时合并回主干，主干上其它版本的缺陷修复视情况是否合并到相应发布分支。
主干开发主干发布是主干开发分支发布的一个特例。适用于团队规模极小、功能相对简单的项目。
历史分支 【版本管理(4)-|版本管理(4)- 简单清晰的分支策略有助于开发】每个发布分支都是一个保留着发布版本的历史分支。
功能分支因为主要的开发活动都发生在主干上，也就是说大多数人的都应该基于主干来做开发。如果是小功能的开发或者是缺陷的修复，应该都直接提交到主干。
对于开发周期较长或者试验性的功能开发应该基于主干建立相应的开发分支，一旦完成则把代码合并回主干。主干依然作为主要的开发分支。这也可以认为是主干开发分支发布模型的一个变体。
发布分支一旦主干上的开发任务基本完成(code complete)，则可以从主干拉出相应的发布分支，用来做将要发布的版本的缺陷修复、发布准备的工作。这个时候的主干上的版本号则一般会增加，下一个发布版本的开发工作继续在主干进行。这个版本的开发工作则都转移到发布分支上来。
不一定选择代码完成的时候拉出相应的发布分支，可以提前（大部分功能完成时），也可以延后（代码足够稳定、缺陷基本修复时），主要视团队规模、产品成熟度、发布周期等。

举个：如果团队规模较大，早拉出相应的发布分支，可以让一部分人继续做系统稳定、缺陷修复的工作；同时可以让团队中的其它人投入到下一个要发布的版本的研发工作中，有利于提供团队产出；也有利于避免不相干代码进入要发布的版本。但是如果团队较小，则可以等代码足够稳定的时候再拉出发布分支，这样也降低了一部分从发布分支合并代码到主干的工作量（因为发布分支上的缺陷肯定在主干上也存在，所以需要把发布分支上代码及时合并到主干上）。
再举个：如果要开发的系统，团队经验不是很多，则稍晚拉出发布分支则是明智选择。否则会涉及大量从分支合并到主干的合并工作。

因为在发布分支上发现的大多数问题在当前的主干上一般也会出现，所以在发布分支上的代码一般都要合并回相应的主干，除非是针对这个版本做的特殊处理或者这个问题在新版本里已经通过其他方式解决。
维护分支维护分支也就是热修复（hotfix）分支。如果系统功能简单，可以快速定位系统问题，则每个发布分支都可以作为相应发布版本的一个维护分支，在发布分支上修复后直接发布；如果遇到 bug 难定位或者需要一定修复时间的缺陷，这个时候可以从发布分支拉出相应的维护分支用来解决相应的问题。解决完之后，代码依然需要合并回发布分支进行发布或者上线。
维护分支的代码一般都要合并到发布分支，然后通过发布分支合并回主干。
小结
主干开发分支发布，清晰易懂、容易维护多版本