个人博客： https://zerogozhang.github.io/
GitHub地址：https://github.com/zeroGozhang/zeroGoZhang.github.io
一、语义化版本控制规范2.0：
1、 语义化版本控制规范
版本格式： 主版本号.次版本号.修订号，版本递增规则如下：
主版本号：做了不兼容的API更改
次版本号：做了向下兼容的功能性新增
修订号：做了向下兼容的问题修正
注： 先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号“后面，作为延伸。
2、版本控制注意事项：
处于开发初始阶段的主版本号为（0.y.z)，该版本为不稳定版
1.0.0 版本用于界定公共API的形成。
次版本号在有向下兼容的新功能出现时递增。 旧功能被弃用也需新增。
主版本号在有任何不兼容的修改被加入公共API时递增。
修订号在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改
二、Git做VCS（版本控制系统）场景的应用：
1、 前言
前面了解了语义化的版本控制定义，这是在软件管理大规模项目沉淀下来的版本控制规范，有效应对大型项目，大量依赖引发的“依赖地狱” 问题。理解语义化版本控制并不难，但如何才能更好的结合在实际开发项目中呢？
2、 基于Git工作流场景的语义化版本控制
2.1 概述：
不像其他的SVN的集中式管理，git的分布式架构给程序员的分工协作带来了极大的舒适感，但也恰是Git的分布式架构，当项目出现了问题，需要回查节点的时候，将会带来一定不便之处。经典分支协作模式大概简单描述：建立分支，进行开发，提交到本地master，删除分支。这样做的后果是以前的修改细节会丢失。众多的commit也会让人眼花缭乱，也给问题定位，历史版本回溯带来麻烦。为解决这种麻烦，以下以Git做VCS的典型协作方式为场景，应用上语义化版本控制规范2.0：
2.2 Git Flow 经典协作模式
核心仓库：master和develop两个分支
分支分类：
核心分支：master和develop分支
支持性分支：特性分支（Feature)，发布分支(Release)，热补丁分支(Hotfix)
这是在网上找到的Git经典工作流图：
单看这图比较杂乱，Git协作方式不在此处讨论，想了解可网上搜索相关资料。推荐文章 图文详解如何利用Git进行团队协作开发。下面我们从一个实例进行一个版本控制
3、 从零开始一个Git Flow工作流
3.1 开发阶段
创建两条主要分支master分支和develop分支，master分支是正式发布的分支，develop为功能的集成分支，master分支每提交一次分配一次版本号。
先创建master分支，此时项目的版本号为 V0.1.0, 处于开发初始阶段的主版本号为（0.y.z)。
master分一个分支到develop分支上。develop可现在本地创建，然后git push到服务器上。
git branch develop
git push -u origin develop
git clone [email protected]:portal/jkq-djh-api.git
git checkout -b develop origin/develop
develop 分支是功能集成分支，每个开发者的功能都会先合并到develop分支上。
3.2 多个开发者各自创建feature分支，新分支的创建需基于develop分支，而非master分支，开发者在各自分支完成开发功能。每个feature分支的合并都应该在develop上，而不应该直接合并到master上。
git checkout -b feature1 develop
3.3 项目完成并准备发布阶段
K8上的版本读取的是package.json文件中的versionf3e0a9f872d511e9823d0a58ac130419 ，version第一版本发布阶段改为V1.0.0，此时提交到master分支时，K8S会自动构建镜像。每次修改到主版本号和此版本号都建议加入Tag标签，方便出现问题时，回查节点。
新建含附注的标签
git tag -a 标签名 -m '附注信息'
eg.
git tag -a v 1.0.0 -m '稳定版本V1.0.0 更新内容：功能1，功能2，功能3'
push标签到远程仓库,git push 并不会把标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。其命令格式如同推送分支，运行 git push origin [tagname] 即可
git push origin v1.0.0
使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象
git show v1.0.0
我们可以引入Git 打标签，结合语义化版本控制的规范，可以直观了解每个版本的API修改内容，向下兼容情况。省去开发人员查看大量commit命令。
规范化的Git 工作流和科学的版本控制，对项目的管理颇有益处，也方便开发人员Debug，版本回滚，历史节点回查。
