1. 如何用 git 打 tag
使用tag标签对重要版本进行标记
当根据项目设计完成所有功能之后，项目就可以进行线上部署了。
为了保留线上项目的历史版本，便于回滚到历史上任意一个上线版本，对于每次进行线上部署，需要使用tag进行管理。
需要回滚到某个历史版本时，切换到对应的tag就可以了。tag不同于分支，而是相当于一个个里程碑，对每个重要的上线版本进行标记。
另外tag不区分分支，在同一个项目不同分支上都可以看见打上去的tag。
1.1 具体命令操作：
创建tag，-a指定标签名，-m是提交信息
git tag -a live1.0.0 -m “live项目第一个上线版本”
不用 -a 选项也可以执行的，但它不会记录这标签是啥时候打的，谁打的，也不会让你添加个标签的注解
这里建议 打tag 必须带上 -a 和 -m
查看tag
git tag
带过滤查询:
git tag -l "live"查看具体某一个 tag 的详情：
git show live1.0.0将tag提交到远程仓库
git push origin live1.0.0
需要回滚切换到这个tag
git checkout v1.0
git reset –hard xxxxxxx
注意：可以利用命令行 git reflog 查询你本地所有操作记录，便于几时回退
基于任意一个commit补上tag
git tag -a live1.0.0 9fceb02 -m “my tag”
删除某个tag
本地删除：
git tag -d v0.1.2 远程删除（一般不删除远程）：
git push origin :refs/tags/v0.1.22. 如何利用 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
- v1.0.0出现BUG，切到该tag版本
此时处于：主分支dev
git checkout v1.0.0当然你也可以使用：
git reset hard --111abc但并不推荐，因为你会失去这个commit之后的所有commit记录，当然也有办法看到，用
git reflog查看你本地的所有记录行为。
- 立马基于v1.0.0，建立新分支 bugfix
此时处于：BUG分支 bugfix
git checeout -b bugfix- 回头来立刻将主分支dev，切换为原来的commit
此时处于最初commit：9527abc
这时回退到tag版本使用的是 git checkout 的优势就有所体现了。
直接运行命令：
git checkout dev即可回到你最初的commit。
- 进入正题，回到BUG分子 bugfix 进行bug修复。
此时处于bug分支： bugfix
git checkout bugfix- 修复完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合并进入才行。
- 合并修复的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上，这里就会存在冲突，需要解决即可。