基于GItFlow模型的研发流程
目前比较流行的分支管理模型有三个，即GitFlow、GitLabFlow、GitHubFlow。结合我们项目发布的实际情况，选用Git Flow模型。
Git Flow 流程图
Git Flow 流程介绍
GitFlow 是最早诞生并得到广泛应用的一种工作流程。
该模型中存在两种长期分支：master 和 develop。 master中存放对外发布的版本，只有稳定的发布版本才会合并到master中。 develop用于日常开发，存放最新的开发版本。
也存在三种临时分支：feature, hotfix, release。
feature分支是为了开发某个特定功能，从develop分支中切出，开发完成后合并到develop分支中。hotfix分支是修复发布后发现的Bug的分支，从master分支中切出，修补完成后再合并到master和develop分支。release分支指发布稳定版本前使用的预发布分支，从develop分支中切出，预发布完成后，合并到develop和master分支中。
优点：
feature 分支使开发代码隔离，可以独立的完成开发、构建、测试，
feature 分支开发周期长于release时，可避免未完成的feature进入生产环境
缺点：
分支管理较为复杂，具有一定的学习曲线，不适合发版周期完全无规划的情形，那种可能在一天内就产生多个版本并需要持续发版的，应该选用GitHub Flow模型。
分支命名规约
| 前缀 | 含义 |
|---|---|
| master | 主分支，可用的、稳定的、可直接发布的版本 |
| develop | 开发主分支，最新的代码分支 |
| feature-** | 功能开发分支 |
| bugfix-** | 未发布bug修复分支 |
| release-** | 预发布分支 |
| hotfix-** | 已发布bug修复分支 |
提交命名规约
除了分支的名称需要规范，提交的命名也同样如此。我们并没有把这个规则固化到开发流程中，需要团队共同遵守。
格式为：[操作类型]操作对象名称，如[ADD]readme，代表增加了readme描述文件。
常见的操作类型有：
-
[IMP] 提升改善正在开发或者已经实现的功能
-
[FIX] 修正BUG
-
[REF] 重构一个功能，对功能重写
-
[ADD] 添加实现新功能
-
[REM] 删除不需要的文件
版本号规范
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
1.主版本号：当你做了不兼容的 API 修改。
2.次版本号：当你做了向下兼容的功能性新增。
3.修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。