前言
本文適用於使用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管理進度。
- 經過兩次
commit操作，新增a.txt和b.txt後，將程式碼修改push到遠端倉庫。
倉庫圖表如下：
master -> * 新增b.txt
|
* 新增a.txt
|
* 初始化
複製程式碼- 給當前文集打個標籤，順便留個心情
// 打標籤
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
|
* 初始化
複製程式碼- 再經過兩次
commit操作，新增c.txt和d.txt後，將程式碼修改push到遠端倉庫。
倉庫圖表如下：
master -> * 新增d.txt
|
* 新增c.txt
|
v0.1.0 -> * 新增b.txt
|
* 新增a.txt
|
* 初始化
複製程式碼- 文集已經寫完，打個完結版的標籤
// 打標籤
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
|
* 初始化
複製程式碼- 過了段時間，我想知道文集在
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 file
複製程式碼1.3 歸納優缺點
- 版本號hash字串不友好，不方便記憶
- 標籤語義化，對開發人員友好，方便提取附註的開發資訊
二、語義化版本控制規範
像上文的栗子，可以看出使用了v0.1.0和v1.0.0打標籤。
其實，這裡遵循了一套語義化版本控制規範（Semantic Versioning）。
規範的概要如下：
版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：
- 主版本號：當你做了不相容的 API 修改，
- 次版本號：當你做了向下相容的功能性新增，
- 修訂號：當你做了向下相容的問題修正。
先行版本號及版本編譯資訊可以加到“主版本號.次版本號.修訂號”的後面，作為延伸。
為什麼要有這套規範，就是為了避免軟體管理的領域裡存在的，稱為“依賴地獄”的死亡之谷。
規範詳情，可以在下面的參考連結獲取。
三、參考
[1] 語義化版本2.0
喜歡我文章的朋友，可以通過以下方式關注我：
- 「star」 或 「watch」 我的GitHub blog
- RSS訂閱我的個人部落格：王先生的基地
