Git上线tag管理规范设计

1. 如何用 git 打 tag

使用tag标签对重要版本进行标记

当根据项目设计完成所有功能之后,项目就可以进行线上部署了。

为了保留线上项目的历史版本,便于回滚到历史上任意一个上线版本,对于每次进行线上部署,需要使用tag进行管理。

需要回滚到某个历史版本时,切换到对应的tag就可以了。tag不同于分支,而是相当于一个个里程碑,对每个重要的上线版本进行标记。

另外tag不区分分支,在同一个项目不同分支上都可以看见打上去的tag。

1.1 具体命令操作:

  1. 创建tag,-a指定标签名,-m是提交信息

    git tag -a live1.0.0 -m “live项目第一个上线版本”

不用 -a 选项也可以执行的,但它不会记录这标签是啥时候打的,谁打的,也不会让你添加个标签的注解

这里建议 打tag 必须带上 -a 和 -m

  1. 查看tag

    git tag

带过滤查询:

git tag -l "live"

查看具体某一个 tag 的详情:

git show live1.0.0
  1. 将tag提交到远程仓库

    git push origin live1.0.0

  2. 需要回滚切换到这个tag

    git checkout v1.0

    git reset –hard xxxxxxx

注意:可以利用命令行 git reflog 查询你本地所有操作记录,便于几时回退

  1. 基于任意一个commit补上tag

    git tag -a live1.0.0 9fceb02 -m “my tag”

  2. 删除某个tag

本地删除:

git tag -d v0.1.2 

远程删除(一般不删除远程):

git push origin :refs/tags/v0.1.2

2. 如何利用 tag 维护线上版本管理并修复 BUG

2.1 版本管理标签定义规则:

版本号格式:X.Y.Z(主版本号,次版本号,补丁版本号)

  • 修复Bug但不影响API增长补丁版本号;

  • API保持向下兼容的增加/修改时增长次版本号;

  • 进行不向下兼容的修改时增长主版本号。

另外注意一点就是,高版次升级,底版次需要清零。

2.2 修复旧版本线上BUG与版本回退具体流程

建设一种场景:

当你某个服务发布了v1.0.0版本,并且打了tag成功上线运行了。

接着开发团队继续在此版本基础上继续进行代码提交各种commit提交了。

这时线上发现以前的v1.0.0版本出现了一个严重的BUG,需要开发团队进行基于该版本的修复并提交,而且不能把后面开发的业务代码提交上线。

解决方案流程:

首先讲讲我们的分支管理:

目前我们项目只有一个主开发分支dev,还没有使用master。

所有开发都是基于dev分支进行fork与pr。

1. 现有情况–只有一个主分支dev版本:

假设此时处于正常开发状态中,保存commit为 9527abc

  1. v1.0.0出现BUG,切到该tag版本

此时处于:主分支dev

git checkout v1.0.0

当然你也可以使用:

git reset hard --111abc

但并不推荐,因为你会失去这个commit之后的所有commit记录,当然也有办法看到,用

git reflog

查看你本地的所有记录行为。

  1. 立马基于v1.0.0,建立新分支 bugfix

此时处于:BUG分支 bugfix

git checeout -b bugfix
  1. 回头来立刻将主分支dev,切换为原来的commit

此时处于最初commit:9527abc

这时回退到tag版本使用的是 git checkout 的优势就有所体现了。

直接运行命令:

git checkout dev

即可回到你最初的commit。

  1. 进入正题,回到BUG分子 bugfix 进行bug修复。

此时处于bug分支: bugfix

git checkout bugfix
  1. 修复完BUG后可以提交限上线了,就要打 tag v1.0.1

此时处于bug分支: bugfix

git tag -a v1.0.1 -m "修复线上BUG,xxxx"

提交这个本地tag 到远处分支:

git push origin v1.0.1

注意:这个时候其实已经可以开始基于tag v1.0.1 上线部署了,毕竟修复BUG赶时间要紧嘛。

修复线上BUG后,你的主开发分支dev,也有可能存在这个bug,所以我们还需要把这个修复后添加的代码版本v1.0.1合并进入才行。

  1. 合并修复的BUG,将分支bugfix合并进入到开发主分支dev

此时处于分支:dev

git checkout dev

git merge --no-ff -m "合并修复bug版本v1.0.1" dev

这里建议 git merge 一定带上 –no-ff 并且加上合并备注

git checkout 可以替换为 git switch

这里的合并,多半会出现冲突,因为这里我们值存在主开发分支dev,两边可能都在基于同一个文件进行更改。解决掉冲突即可。

(其实可以设置master分支专门放发行版本的代码和tag,就很省去一些中间时间,如下的设计情况)

现有情况总结:

  • 回退到打标签的那次提交
  • 再新建分支bugfix
  • 在bugfix分支,修改bug,发版本,打新标签,手动推送标签到远程(测试后可以上线发版)
  • 合并bugfix分支到主干上

2. 设计情况–dev开发主分支,master发版分支,release 打 tag临时分支:

主要操作流程基本与上面的情况一样,命令行基本相同,这个设计不同情况在于,设置多分支来作为不同功能,有有利版本管理高效、干净。

  • 主要开发代码依旧在 dev 分支
  • master 分支放的都是我们的发行正式版,包含全部上线应有的tag
  • release 专门用来临时打 tag,每次打完合并到master分支、dev分支。

这里简单说明一些流程问题:

首选master分支要禁止直接push,所以要采取合并的方式

  • 回退到打标签的那次提交
  • 新建bug分支修复
  • 在bugfix分支,修改bug。推送待测试环境,进行测试
  • 测试通过后切换分支release,发版本,打新标签,手动推送标签到远程。(这里其实就可以发版上线了,合并问题后续处理)
  • 合并到master分支,这里应该不会存在冲突问题
  • 合并bugfix分支到开发分支dev上,这里就会存在冲突,需要解决即可。

参考:

Git如何优雅地回退代码

公司使用Gitlab管理项目实践指南