author：crylearner

ü  功能开发 (开发人员)

ü  bug修复，包括测试版本的bugfix和生产版本的hotfix (开发人员)

ü  版本集成，包括发布测试版本和生产版本 (项目经理)

ü  版本测试 (测试人员)

ü  保证bug修复与功能开发并行，不会出现堵塞情形。

ü  保证可以快速版本集成。

实现方式就是多分支 + 里程碑标记

开发人员日常开发时使用的分支，它代表着最新的开发状态。大多数的时候，最新节点的版本是未经检验的、不可靠的。

为了使develop的开发状态可控，根据代码提交频度，定期做一次集成+基本用例测试。如果可以引入单元测试，就更好了。

特性开发分支作为对开发分支的补充，保证不会因为特性开发的不完整，导致develop开发分支的不稳定。

对大型功能的开发，或者试验性的开发，可以单独在本地检出feature分支进行开发。只要定期自己将develop分支的内容同步过来即可。

代表着稳定状态的分支。任何时候，master分支的最新节点应该都是随时可发布的。

当完成一个里程碑时(完成版本发布、完成hotfix)，应该在主干分支上打上tag，同时将变更内容同步到开发分支。

实际一般主要用于发布测试版本，并提供开发人员在此分支上完成测试版本的bug修复。(如果是发布生产版本，一般直接取用某个测试版本即可)

ü  测试版本应该从开发版本的当前最新节点检出。为了尽可能保证该节点的稳定性，项目经理应该提前通知开发人员做好代码提交。

ü  修复bug时，可采用敏捷方式。通过每日集成+回归测试（只测试最新标记为修复的bug），完成快速迭代。

ü  bug修复完成后，由项目经理将分支合入主干，并打上tag，同时将主干内容同步到开发分支develop。 bug修复完成后，release分支也不再有存在价值，可以由项目经理删除。

修复时，从主干分支上找到对应该生产版本的tag。基于此tag检出hotfix分支，完成修复后合入到主干master，同时打上tag，删除hotfix分支。（同时也别忘了将主干分支往开发分支做一次正向同步）

后记：如果是基于git的版本控制，只有develop分支是必需长期存在的，其他分支事实上都是可以临时性质的。也就是表面上的单分支，也是我以前公司使用的策略（不过也不完全一致，因为完全的多分支管理也确实比较复杂）。

参考文档：主要是基于第一份参考文档。

1. 《一个成功的Git分支策略模型》

2. 《有策略的进行分支》

3. 《敏捷开发模式中的分支管理模式》

4. 《敏捷开发模式中的分支管理模式实战与补遗》