git_version_control_proper_practice

git_version_control_proper_practice

version control，版本控制的方法之一就是打tag

因为多人协作的项目团队，commit很多，所以需要给重要的commit打tag，方便checkout，检出这个tag

参考行业的实践方式。如图git、linux、kubernetes

在实际应用中可以参考。

打包h-uat部署包时，给commit打一个v1.8.5-rc0的包，在h-uat部署过程中发现的问题，部署仓代码进行的修改，打v1.8.5-rc1、v1.8.5-rc2、v1.8.5-rc3这样的tag，

当h-uat和压测环境验证OK了，准备打生产环境的包了，就给生产环境要打包的commit打一个v1.8.5 -a -m "official version for v1.8.5"的正式包的标签。后面需要新环境部署这个版本的时候，可以checkout v1.8.5这个正式版的标签，来使用这个版本的部署仓。更常用的是要把这个tag的部署仓代码合并到主分支，比如dev

> git tag -l 'v1.8.5*'  # 查找正式版的标签，及rc版"release candidate",
> git show v1.8.5  # 查看标签详细情况，包括metadata和annotate
> git checkout dev
> git merge v1.8.5

如果生产环境有紧急问题或者小问题需要快速修复，两种方式，生产环境修改代码或配置，能快速解决问题；第二种方式，放到下个修订版（PATCH）进行部署。无论是这两种方式的哪一种，都需要修改部署仓，而部署仓的这些修改都属于下个修订版要release的东西。所以在v1.8.5之后不用再打tag，需要等到下个版本准备h-uat测试的时候，开始打v1.8.6-rc0，然后h-uat和压测环境测试的过程中，发生的修改，打v1.8.6-rc1、v1.8.6-rc2这样的tag，然后打包完成生产部署包之后，这个包已经发往生产环境之后，打一个v1.8.6 -a -m "official version for release v1.8.6"的tag。然后后面的更改，现场发现的问题，或者开发测试自己发现的bug，无论是发版改还是现场直接改，都属于下个修订版（PATCH）或次版本（MINOR）的内容。继续按照v1.8.7-rc0的形式在h-uat测试的时候打tag。这样应该是规范的