分支规范

1、目的

 咱们制定分支规范，意在实现如下目标：

1. 减小沟通成本：开发者能够很清晰地知道须要修改的代码位于哪一个分支。
2. 减小 bug 隐患：避免因分支合并致使 bug。
3. 维护线上稳定：经过必定的流程规范，保证线上代码安全。
4. 灵活：支持多版本同时开发、同时发布。
5. 简洁：用最少的分支解决问题，避免反复建立、合并分支，节约操做时间。

2、主分支: master

主分支(master)用于存放最新的稳定版本。

正式发布时：在主分支上建立标签(tag)。若是发布很是频繁能够不加。

标签的命名规范为：release-v版本号-日期(如 release-v0.0.1-20161010)。业务项目能够不加版本号；框架、工具项目能够不加日期。

release-xx 分支：若是须要同时维护多个发布版本（好比有些框架在发布新版同时还会更新老版），则须要基于 master 分支建立名为 release-v版本号前缀(如 release-v1.x)的分支，以后 master 分支持续更新为最新稳定版，release-xx 分支则持续更新为对应版本的最新稳定版。全部 release-xx 分支和 master 分支地位相同，master 至关因而 release-latest 分支。

3、开发分支: dev-xx

dev 分支用于存放最新代码(可能包含未测试的代码)，只有须要正式发布时才会合并到 master 分支。

若是项目对稳定性要求不高（好比小项目、练习用的代码），则能够不建 dev-xx 分支，而直接在 master 分支修改。

开发时：基于 master 分支建立名为 dev-v版本号(如 dev-v0.0.1)的分支。业务项目能够不加版本号，固定为 dev 分支。

开发完成后发布测试：直接发布 dev 分支到测试环境。若是测试出现 bug 则在 dev 分支继续修复。

测试完成后正式发布：将 dev 分支合并到 master 分支。而后发布 master 分支。

若是须要同时开发多个版本，能够从 master 建立多个不一样版本号的 dev-xx 分支。每次发布后其它 dev-xx 分支须要从 master 分支合并最新的改动。

4、修复分支: bugfix-xx

发布后线上发现 bug 时：

• bug 影响不大：建议在 dev-xx 分支中修复，等待下次发布时修复。
• bug 影响很大：将线上代码回滚到 master 分支的上一个标签(或最近的 release-xx 分支)。
• bug 影响通常：从 master 分支建立名为 bugfix-时间(如 bugfix-20161010190000) 的分支，在此分支修复 bug，修复完成后直接将 bugfix-xx 分支发布上线。若是上线后 BUG 已解决则将 bugfix-xx 分支合并到 master 分支并删除 bugfix-xx 分支。若是 bug 仍未解决，则继续在此分支修复 bug 直到解决。

5、构建分支: build-xx

有些项目须要预编译(压缩、优化)代码才能发布上线，全部分支在发布时都会先合并到同名的 build-xx 分支。

如 dev-0.0.1 在发布测试环境时，须要先合并到 build-dev-0.0.1 分支，而后通过预编译后发布 build-dev-0.0.1 分支。

如 dev-0.0.1 在发布正式环境时，须要先合并到 master 分支，而后合并到 build-master 分支，而后通过预编译后发布 build-master 分支。

build-xx 分支可使用构建工具自动维护。大部分状况开发者不须要关心此分支，除非发现因自动构建致使的 bug 时，开发者能够切到此分支查找问题。

6、其它分支

根据项目实际需求，能够建立其它分支，如 github 页面须要的 gh_pages 等分支。

7、总结

分支总共有：master、dev-xx、release-xx、bugfix-xx、build-xx 五类。大部分项目只需建立前面 2 个分支，其他的根据须要再建。开发者平时只需维护 dev-xx 分支。dev-xx 的代码只能发布到测试环境，不能直接发布上线。