一、目的
我们制定分支规范，意在实现以下目标：
- 减少沟通成本：开发者可以很清晰地知道需要修改的代码位于哪个分支。
- 减少 bug 隐患：避免因分支合并导致 bug。
- 维护线上稳定：通过一定的流程规范，保证线上代码安全。
- 灵活：支持多版本同时开发、同时发布。
- 简洁：用最少的分支解决问题，避免反复创建、合并分支，节约操作时间。
二、主分支: 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 分支。
三、开发分支: 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 分支合并最新的改动。
四、修复分支: 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 直到解决。
五、构建分支: 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 时，开发者可以切到此分支查找问题。
六、其它分支
根据项目实际需求，可以创建其它分支，如 github 页面需要的 gh_pages 等分支。
七、总结
分支总共有：master、dev-xx、release-xx、bugfix-xx、build-xx 五类。大部分项目只需创建前面 2 个分支，其余的根据需要再建。开发者平时只需维护 dev-xx 分支。dev-xx 的代码只能发布到测试环境，不能直接发布上线。
