1、 命名规范
X.Y.Z = 主版本号.子版本号.修正版本号

2 、命名原则
（1）项目初版本时，版本号可以为 0.1.0；

（2）当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1;

（3）当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0；

（4）当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1;

3 、案例
主版本号改动：一期项目用0.1.0；二期项目用1.1.0；三期项目用 2.1.0；默认最大值：99

子版本号改动：增加了权限管理功能模块，版本号由0.1.3改为 0.2.0；默认最大值：99

修正版本号改动：修正了一个页面显示字符串，版本号由0.1.3改为0.1.4；默认最大值可以是：99

4、测试环境发包命名规则
在版本号的规则上，增加一条尾巴作为测试发布的打包号（毕竟有些小改动要测试几次才能通过）

X.Y.Z - betaNum = 主版本号.子版本号.修正版本号 - beta测试发布号

比如

例子A - 子版本：v1.2.0 的第一次测试发版打包号为：v.1.2.0-beta1，第二次测试发版打包号为：v1.2.0-beta2，依此类推。

例子B - 子版本的修正版本：v1.2.1 的第一次测试发版打包号：v1.2.1-beta1，第二次测试发版打包号为：v1.2.0-beta2，一次类推。

注意：测试阶段的镜像不需要推到阿里云仓库，所以要把gitlab中推送到阿里云的stage 注释掉

5、IDC环境（线上正式环境）发包命名规则
正式环境的版本发包号只需要把测试环境所打的版本的尾巴去掉，即默认为正式环境的发包号。比如测试环境的发包号为：v1.2.0-betaX，那么就可以打成 v1.2.0 或者 v1.2.0-release 进行发布（此时可以合并到release分支或者master分支）。

注意：记得把gitlab-ci中的stage打开，将镜像推送到阿里云镜像仓库。

6、Git分支命名建议
开始新的版本（主版本或者子版本必须开新的分支进行开发），修改版本可以考虑不用开新的分支，但是如果两个人一起开发同一个项目，建议开新的分支。

分支好命名和版本号一致，可以适当增加一个release分支，发版后版本分支合并回release分支后，打tag进行发布。