常见的分支开发模式

• 主干开发，主干发布
• 主干开发，分支发布
• 分支开发，分支发布

主干开发，主干发布

模式：

​ 是指开发人员向主干分支上提交代码，并且主干分支用于软件交付。所有新特性的开发代码都提交到主干分支上，当需要发布新功能时候，直接将主干上的代码部署到生产环境上。

优点：分支简单，分支管理的工作量少

缺点：在缺陷修复阶段，并不是所有开发人员做缺陷修复，这样就会有一定资源的浪费。

​ 当有分支开发周期长的情况下，分支难以向主干分支合并

最佳软件质量管理实践：未完成的功能代码不能带入将要发布的版本里

主干开发，分支发布

模式：

• 开发人员将写好的代码提交到主干
• 当新本的功能全部开发完成或者已经接近版本发布时间点的时候，从主干上拉取一个新的分支
• 在这个新分支上进行集成测试，并修复缺陷，进行版本质量打磨。当质量达标后，再对外发布该版本。

特点：

• 主干代码提交活动频繁，对保障主干代码质量有较大的挑战；
• 分支只修复缺陷，不增加新功能;
• 新版本发布后，如果发现严重缺陷，而且必须立即修复的话，只要在该版本所属的分支上秀谷后，再次发布补丁版本，然后将分支上的修该合并会主干即可；也可以在主干上修复缺陷，然后将针对该缺陷修复的代码挑出来，合并到该缺陷所在的分支上。（FaceBook 移动端）

优点：

• 与将要发布的新功能无关的人员可以持续工作在开发主干上，不受版本发布的影响
• 新发布的版本出现缺陷后，可以直接在其自己的版本发布分支上进行修复，简单便捷。即使当前开发主干上的代码已经发生变化，该分支也不会受到影响。

缺点：

• 主干上的代码通常只能针对下一个新发布版本的功能开发。只要心发布版本的任何功能在主干上还没有开发完成，就不能创建版本发布分支，否则很有可能影响下一个发布的开发计划，开源项目的在发布时间点以及特性功能方面的压力小一些，因此常常采用这种分支方式。
• 使用这种开发模式，对发布分支的数量不加约束，并且分支周期较长，很容易出现"分支地狱"倾向，这种倾向常见于”系列话产品簇+个性化定制“的项目。（定制化开发）

分支开发，主干发布

模式：

• 团队从主干上拉出分支，并在分支上开发软件新功能或修复缺陷
• 当某个分支(或多个分支)上的功能开发完成后要对外发布版本时，才合入主干
• 通常在主干上进行缺陷修复，质量达标后，再将主干上的代码打包发布。

优点：

• 在分支合并之前，每个分支之间的开发活动互相不受影响
• 院队可以自由选择的发布哪个分支上的特性
• 如果新版本出现缺陷，可以直接在主干上进行修复或者使用hotfix分支秀谷，简单便捷，无须考虑其他分支。

缺点：

• 为了分支之间少受影响，开发人员通常会减少向主干代码合并代码的频率，从而推迟了发现各分支中代码冲突的时间，不利于及时进行代码重构
• 如果分支过多，当某个分支的生命周期（从主干拉出分支到合并主干的这段时间周期）过长，代码合并以及验收成功会快速增加；成本增加的数量与其生命周期中合入主干的分支数量成正比。

使用规范:

• 让主干尽可能一一直保持在可发布状态
• 每个分支的生命周期应该尽可能短
• 主干代码今早与分支同步
• 一切与主干代码为主，尽可能不要在各特性分支之间合并代码

衍生:

• 特性分支模式
• 团队分支模式

特性分支模式：

模式：

• 多个开发分支同时存在，每个分支对应一个功能特性的开发工作
• 当该特性开发完成后，立即合入主干。
• 其他尚未合入主干的特性分支需要从主干分支拉取主干代码， 与自己分支上的代码进行合并后，才能再合回主干

优点：

• 团队在“特性”这个层次上可以并行工作，同时保持主干分支的稳定可发布状态
• 每次发布内容调整起来容易

缺点：

• 如果特性分支过多，会带来比较多的合并成本

使用规范：

• 每个特性分支的生命周期都应该很短，分支上的开发和测试工作尽量在3天内完成。这要求尽可能将特性拆分成小需求。
• 开发人员每天从主干上拉去最新的可交付代码，与自己的分支合并。
• 不要从其他特性分支上拉去代码

团队分支模式：

模式：

• 一组人一起在同一个分支上进行开发，并且该分支通常包括一组相近或者相关的特性集合的开发。
• 由于是一组特性开发，因此其分支存续时间比特性分支持续时间比较长

应用于大型开发团队(40人以上)共同开发一款产品，团队被分成多个组，每个组开发不同的系统组件，只有当一系列的组件开发完成后，才对外发布新的软件版本。

使用规范：

• 每个团队尽早向主干合入高质量代码，即使不马上发布。
• 想主干合入代码后，尽快使其达到可交付状态
• 其他团队尽早从主干拉取可交付状态的代码，与自己分支上的代码合并

分支模式的演化

“三架马车”分支模式：

模式：

团队仅维护三个分支：开发分支，预发布分支，发布分支

1. 开发分支就是所有的开发人员提交代码的目标分支。
2. 当接近发布时，将开发分支中准备发布的代码分拣(cherry pick)到预发布分支上
3. 预发布分支只做缺陷修复，文档生成以及发布相关的工作，不做新功能开发
4. 预发布分支达到Alpha版本发布质量的时候，发布Alpha版本
5. 进一步发布beta版本
6. 当beta版本稳定后，合入发布分支，发布RC(Release Candidate)版本
7. RC版本稳定，即可作为稳定发布版本

Gitflow分支模式

很多企业所应用的模式

模式：

1. Master分支是正式版本的发布分支
2. Release分支是用于质量打磨的预发布版本分支。如果Rlease分支的质量达标，就可以将其合入Master分支，同时也需要将代码合入Development分支
3. Development分支是对新功能进行集成的分支
4. Feature分支是为了开发某一功能特性，开发人员从Development分支上拉出的分支。当特性开发完成之后，合入Development分支。
5. 如果已经发布的版本（v0.1）出现了严重对的缺陷，从Master分支上v0.1版本标签处 拉出hotfix分支，在这个分支上修复缺陷，验证后再次合入Master分支，并发布新的补丁版本v0.2。与此同时，由于Development分支上也有同样的缺陷存在,因此开发人员还要将Hotfix分支的代码一直到Devemlopment分支上，以修复Development分支 上的缺陷。

Gitflow分支模式是特性分支模式和**“三驾马车”分支模式**的组合，

优点：每个分支的定义都明确且清晰，

缺点：分支不足，具有特性分支的不足

GithubFlow分支模式

来源github工作团队的实践

1. 从master上创建一个新的分支，以这个特性或者缺陷的编号命名该分支
2. 在这个新创建的分支上提交代码
3. 功能开发完成，并自测通过，创建PR（Pull Request）
4. 其他开发人员对这个PR进行审查,确认质量合格后,合入master

如果特性分支的存在时间很短，则该模式可被认为是高频的：“主干开发，主干发布” 模式

*摘录自《持续交付2.0》