Git操作规范之tag的使用技巧详解

常用分支

master

develop

release

hotfix

使用

注意

tag规范

打tag场景

tag命名规范

版本类型说明

版本号设置规范

场景举例

新需求

修复bug

重大版本更新

特殊情况

首先分享一下我们的分支规范，然后再介绍摸索出的打tag的规范。

master : 主分支 , 最终在master分支对外发布，

此分支只能从其他分支合并，不能再这个分支直接修改

另外所有在master分支的推送应该打标签做记录,方便追溯

例如release合并到master

主测试分支 , 基于master分支创建

包含所有要发布到下一个版本的代码

只能从其他分支合并

release 分支开发完成合并到develop

开发分支, 基于master分支创建

主要用于新需求新功能的开发

功能开发完毕后合到develop分支发布测试环境，测试通过后合并到master发布生产环境

release可同时存在多个

补丁分支 , 基于master分支创建

主要用于对线上的版本进行BUG修复

修复完毕后合并到develop分支发布测试环境，测试通过后合并到master发布生产环境

属于临时分支 , 补丁修复上线后可选删除

初始化项目 , 默认创建master分支

从master拉取第一个develop分支

从master拉取第一个release分支(多个开发人员拉取多个release同时进行并行开发 , 互不影响)

release分支完成后 , 合并到develop

从develop分支打tag进行提测，提测过程中在原release分支修改BUG，重复步骤4

测试通过后合并release到master，基于master分支打tag发布生产环境.此时可删除当前release分支

上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改

hotfix通过测试上线后可选删除当前hotfix

发布线上时一定是master合并开发分支，develop分支可能存在其它未测试通过代码

两个分支进行合并时一定要拉取一下最新代码

在测试同学线上回归测试之后一定要给master分支添加tag，方便后续有需求时快速回滚到指定的稳定版本

当一个代码库在同一个时间段有多个需求要按顺序上线时，运维同学需要通过tag标记区分要构建的代码，这时候需要添加tag。

版本类型_版本号

比如：stable_v1.1.0

意为：稳定版v1.1.0

pre类型的tag应该在测试同学回归测试通过，打完stable类型或者hotfix类型的tag之后删除。

代码仓库只保留stable类型和hotfix类型的tag，方便回滚到稳定版本；不保留pre这种过渡类型的tag。

比如版本号：v1.0.0

第一个数字1，代表大版本，默认从1开始，大版本更新时才递增

第二个数字0，代表小版本更新，默认从0开始

第三个数字0，代表补丁版本，默认从0开始

注意:在打tag的时候需要设置message，写清楚注释。

tag name命名规范：stable_v1.0.0

tag message：云仓商品添加销量字段

tag name 命名规范：hotfix_v1.0.1

tag message：修复XXX bug

tag name 命名规范：stable_v2.0.0

tag message：项目整体重构后上线

预发布环境，需要按顺序构建的：

tag name 命名规范：pre_v1.0.1

tag message：预发布tag：商品中心上线

tag name 命名规范：pre_v1.0.2

tag message：预发布tag：新渠道上线

以上就是Git操作规范之tag的使用技巧详解的详细内容，更多关于Git tag操作规范的资料请关注易知道(ezd.cc)其它相关文章！