個人博客： 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，版本回滾，歷史節點回查。
