Git打標籤與版本控制規範

前言

本文適用於使用Git作VCS（版本控制系統）的場景。

用過Git的程序猿，都喜歡其分佈式架構帶來的commit快感。不用像使用SVN這種集中式版本管理系統，每一次提交代碼，都要爲代碼衝突捏一把冷汗。 頻繁commit的背後，帶來的結果是一長串密密麻麻的提交記錄。 一旦項目出現問題，須要檢查某個節點的代碼問題，就會有點頭疼。 雖然有commit message，但仍是有存在查找困難和描述不清的問題。

本文的側重點，就是經過Git的打標籤功能git tag來解決這個問題，並用SemVer（語義化版本控制規範）規範標籤的命名。

1、打標籤

打標籤的做用，就是給項目的開發節點，加上語義化的名字，也即功能版本的別名。 打上標籤名的同時，寫上附帶信息，能夠方便項目往後維護過程當中的回溯和複查。 另外，也能夠經過標籤記錄，大體瞭解當前項目的向下兼容性、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 file
複製代碼

1.3 概括優缺點

• 版本號hash字符串不友好，不方便記憶
• 標籤語義化，對開發人員友好，方便提取附註的開發信息

2、語義化版本控制規範

像上文的栗子，能夠看出使用了v0.1.0和v1.0.0打標籤。 其實，這裏遵循了一套語義化版本控制規範（Semantic Versioning）。

規範的概要以下：

版本格式：主版本號.次版本號.修訂號，版本號遞增規則以下：

1. 主版本號：當你作了不兼容的 API 修改，
2. 次版本號：當你作了向下兼容的功能性新增，
3. 修訂號：當你作了向下兼容的問題修正。

先行版本號及版本編譯信息能夠加到「主版本號.次版本號.修訂號」的後面，做爲延伸。

爲何要有這套規範，就是爲了不軟件管理的領域裏存在的，稱爲「依賴地獄」的死亡之谷。

規範詳情，能夠在下面的參考連接獲取。

3、參考

[1] 語義化版本2.0

---

喜歡我文章的朋友，能夠經過如下方式關注我：

• 「star」 或 「watch」 個人GitHub blog
• RSS訂閱個人我的博客：王先生的基地