基于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.修订号:当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。