Git打标签与版本控制规范
前言
本文适用于使用Git做VCS（版本控制系统）的场景。
用过Git的程序猿，都喜欢其分布式架构带来的commit快感。不用像使用SVN这种集中式版本管理系统，每一次提交代码，都要为代码冲突捏一把冷汗。
频繁commit的背后，带来的结果是一长串密密麻麻的提交记录。
一旦项目出现问题，需要检查某个节点的代码问题，就会有点头疼。
虽然有commit message，但还是有存在查找困难和描述不清的问题。
本文的侧重点，就是通过Git的打标签功能git tag来解决这个问题，并用SemVer（语义化版本控制规范）规范标签的命名。
一、打标签
打标签的作用，就是给项目的开发节点，加上语义化的名字，也即功能版本的别名。
打上标签名的同时，写上附带信息，可以方便项目日后维护过程中的回溯和复查。
另外，也可以通过标签记录，大致了解当前项目的向下兼容性、API的修改和迭代情况。
1.1 打标签命令
一般推荐打带附注信息的标签，这样可以最大限度查看标签版本的修改情况。
// 命令格式
git tag -a 标签名 -m "附注信息"
// 示例
git tag -a v0.1.0 -m "完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！"1.2 举个栗子
一份文集等待出版，有
a、b、c、d四篇。
现在通过Git管理进度。
1.经过两次commit操作，添加a.txt和b.txt后，将代码修改push到远程仓库。
仓库图表如下：
master -> * 添加b.txt
|
* 添加a.txt
|
* 初始化2.给当前文集打个标签，顺便留个心情
// 打标签
git tag -a v0.1.0 -m "完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！"
// push 标签到远程仓库
git push origin v0.1.0仓库图表如下：
master v0.1.0 -> * 添加b.txt
|
* 添加a.txt
|
* 初始化3.再经过两次commit操作，添加c.txt和d.txt后，将代码修改push到远程仓库。
仓库图表如下：
master -> * 添加d.txt
|
* 添加c.txt
|
v0.1.0 -> * 添加b.txt
|
* 添加a.txt
|
* 初始化4.文集已经写完，打个完结版的标签
// 打标签
git tag -a v1.0.0 -m "文集完成，共4篇文章，等出版。"
// push 标签到远程仓库
git push origin v1.0.0仓库图表如下：
master v1.0.0 -> * 添加d.txt
|
* 添加c.txt
|
v0.1.0 -> * 添加b.txt
|
* 添加a.txt
|
* 初始化5.过了段时间，我想知道文集在v0.1.0版本的情况
// 输出v0.1.0的详情
git show v0.1.0
// 输出结果
tag v0.1.0
Tagger: wall <582104384@qq.com>
Date: Wed May 23 15:57:13 2018 +0800
完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！
commit 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6 (tag: v0.1.0)
Author: wall <582104384@qq.com>
Date: Wed May 23 15:27:10 2018 +0800
添加b.txt
diff --git a/src/b.txt b/src/b.txt
new file mode 100644
index 0000000..f9ee20e
--- /dev/null
+++ b/src/b.txt这里，可以清晰地看到当时打标签的内容和附注信息。
还有另外一个方便的点，就是不需要用hash字符串表示的版本号去查看更改。
以下是用版本号查询的结果：
// 用版本号查看
git show 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6
// 输出结果
commit 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6 (tag: v0.1.0)
Author: wall <582104384@qq.com>
Date: Wed May 23 15:27:10 2018 +0800
添加b.txt
diff --git a/src/b.txt b/src/b.txt
new file mode 100644
index 0000000..f9ee20e
--- /dev/null
+++ b/src/b.txt
@@ -0,0 +1 @@
+This is B.
\ No newline at end of file1.3 归纳优缺点
- 版本号hash字符串不友好，不方便记忆
- 标签语义化，对开发人员友好，方便提取附注的开发信息
二、语义化版本控制规范
像上文的栗子，可以看出使用了v0.1.0和v1.0.0打标签。
其实，这里遵循了一套语义化版本控制规范（Semantic Versioning）。
规范的概要如下：
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
为什么要有这套规范，就是为了避免软件管理的领域里存在的，称为“依赖地狱”的死亡之谷。
规范详情，可以在下面的参考链接获取。
三、参考
[1] 语义化版本2.0