程式碼分支及版本管理規範

目的

為了規範程式碼庫分支管理 和 版本管理，使程式碼分支及版本結構清晰，方便維護，並避免由於維護造成的錯誤的版本釋出等問題。

Git 分支管理

通常每個應用或者是二方庫的程式碼將包括 master、develop、release、hotfix、feature分支，release、hotfix 分支的命名規則分別為：release-*，hotfix-*。feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱。

各分支使用辦法說明如下：

master分支

master和develop分支都是主分支，主分支是所有開發活動的核心分支。所有的開發活動產生的輸出物最終都會反映到主分支的程式碼中。

master分支上存放的應該是隨時可供在生產環境中部署的程式碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的程式碼時，master分支上的程式碼會被更新。同時，每一次更新，都有對應的版本號標籤（TAG）。

develop分支

develop分支是儲存當前最新開發成果的分支。通常這個分支上的程式碼也是可進行每日夜間釋出的程式碼（Nightly build）。因此這個分支有時也可以被稱作“integration branch”。

當develop分支上的程式碼已實現了軟體需求說明書中所有的功能，通過了所有的測試後，並且程式碼已經足夠穩定時，就可以將所有的開發成果合併回master分支了。對於master分支上的新提交的程式碼建議都打上一個新的版本號標籤（TAG），供後續程式碼跟蹤使用。

release分支

使用規範：

1.可以從develop分支派生

2.必須合併回develop分支和master分支

3.分支命名慣例：release-*

release分支是為釋出新的產品版本而設計的。在這個分支上的程式碼允許做小的缺陷修正、準備釋出版本所需的各項說明資訊（版本號、釋出時間、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閒出來以接受新的feature分支上的程式碼提交，進入新的軟體開發迭代週期。

當develop分支上的程式碼已經包含了所有即將釋出的版本中所計劃包含的軟體功能，並且已通過所有測試時，我們就可以考慮準備建立release分支了。而所有在當前即將釋出的版本之外的業務需求一定要確保不能混到release分支之內（避免由此引入一些不可控的系統缺陷）。

成功的派生了release分支，並被賦予版本號之後，develop分支就可以為“下一個版本”服務了。所謂的“下一個版本”是在當前即將釋出的版本之後釋出的版本。版本號的命名可以依據專案定義的版本號命名規則進行。

hotfix分支

使用規範：

1.可以從master分支派生

2.必須合併回master分支和develop分支

3.分支命名慣例：hotfix-*

除了是計劃外建立的以外，hotfix分支與release分支十分相似：都可以產生一個新的可供在生產環境部署的軟體版本。當生產環境中的軟體遇到了異常情況或者發現了嚴重到必須立即修復的軟體缺陷的時候，就需要從master分支上指定的TAG版本派生hotfix分支來組織程式碼的緊急修復工作。

feature分支

使用規範：

1.可以從develop分支發起feature分支

2.程式碼必須合併回develop分支

3.feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱

feature分支（有時也可以被叫做“topic分支”）通常是在開發一項新的軟體功能的時候使用，這個分支上的程式碼變更最終合併回develop分支或者乾脆被拋棄掉（例如實驗性且效果不好的程式碼變更）。

一般而言，feature分支程式碼可以儲存在開發者自己的程式碼庫中而不強制提交到主程式碼庫裡。

版本號管理

1. 版本號命名規則

a. 庫結構版本號

版本號的格式：w<主版本號>.<副版本號>.<釋出號>/t<主版本號>.<副版本號>.<釋出號>

版本號的初始值：w1.0.0/t1.0.0

管理規則:

主版本號（Major version）

1．設定時間：資料庫結構處理完畢，待發布給相關組之前確定。

2．設定部門：開發組設定（告知資料結構管理員）。

3．設定規則：

1） 涉及到大於10個表的增刪時，主版本號加1；

副版本號（Minor version）

1．設定時間：資料庫結構處理完畢，待發布給相關組之前確定。

2．設定部門：開發組設定（告知資料結構管理員）。

3．設定規則：

1） 主版本號變更時，副版本號置0。

2） 涉及到小於等於10個表或欄位的增刪時，副版本號加1；

3） 若副版本號累加至超過20時，採用主版本號進位制，主版本號加1，副版本號重新置0；

釋出號（Release）

1．設定時間：資料庫結構處理完畢，待發布給相關組之前確定。

2．設定部門：開發組設定（告知資料結構管理員）。

3．設定規則：

1）主版本號或副版本號變更時，Release號置0。

2）僅涉及欄位含義調整、標置位的含義、索引和同義名調整時，則Release號加1；

b. 業務版本號

版本號的格式：w<主版本號>.<副版本號>.<釋出號>/t<主版本號>.<副版本號>.<釋出號>

版本號的初始值：w1.0.0/t1.0.0

管理規則:

主版本號（Major version）

1．設定時間：產品預計釋出時。

2．設定部門：開發組設定。

3．設定規則：

1） 產品的主體構件進行重大修改，主版本號加1；

2） 產品的主體構件之間的介面協議重大修改，主版本號加1。? 副版本號（Minor version）

1．設定時間：產品預計釋出及版本預計更新時。

2．設定部門：開發組設定。

3．設定規則：

1） 主版本號變更時，副版本號置0；

2） 資料結構變更(新增或修改註釋含義的情況除外)，副版本號加1；

3） 若副版本號累加至超過20時，採用主版本號進位制，主版本號加1，副版本號重新置0。

釋出號（Release）

1．設定時間：產品預計釋出及版本預計更新時。

2．設定部門：開發組設定。

3．設定規則：

1）主版本號或副版本號變更時，Release號置0；

2）若釋出的版本無資料結構變更，則Release號加1。

注：主版本號和副版本號的變更標誌著重要的功能或結構變動。Release號的變更，用於體現小的功能變更或用來管理專案的分支。

2. 專案週期內版本號變化規則

目前我們使用工程集的方式使用maven組織原始碼專案過程中將涉及到一個war包及其依賴的子工程的版本協調問題，其版本號變化原則如下：

a、xxx.war 的版本號變化規則是：在每個web應用程式的迭代週期開始時主版本號 增1，次版本號和釋出號都從0開始。

b、xxx.web 的版本號變化規則是：在每個web應用程式的迭代週期內，只有當其程式碼有變更的時候才變化其版本號，其版本號與xxx.war保持一致。

c、xxx.impl 的版本號變化規則是：在每個web應用程式或者java應用程式的迭代週期內，只有當其程式碼有變更的時候才變化其版本號，其版本號與xxx.war保持一致。

d、xxx.service 的版本號變化規則是：在每個web應用程式或者java應用程式的迭代週期內，只有當其程式碼有變更的時候才變化其版本號，其版本號與xxx.war保持一致。

e、xxx.dao 的版本號變化規則是：在每個web應用程式或者java應用程式的迭代週期內，只有當其程式碼有變更的時候才變化其版本號，其版本號與xxx.war保持一致。

f、xxx 的版本號在其子工程內程式碼有變化的情況下都將隨之變化， 其版本號與xxx.war或者xxx.task保持一致。

g、為避免war和task的版本號重複，war子工程及隨war變化的子工程的版本號以“w”開頭，task子工程及隨task變化的子工程的版本號以“t”開頭，

3.專案週期內版本號變化規則

開發階段版本號後面要加 snapshot

到提測試的時候每次打包 RC字尾加1

注：

Alpha：是內部測試版,一般不向外部發布,會有很多Bug.一般只有測試人員使用。

Beta：也是測試版，這個階段的版本會一直加入新的功能。在Alpha版之後推出。

RC：(Release　Candidate) 顧名思義麼 ! 用在軟體上就是候選版本。系統平臺上就是發行候選版本。RC版不會再加入新的功能了，主要著重於除錯。

GA:General Availability,正式釋出的版本，在國外都是用GA來說明release版本的。

 

轉：http://www.uml.org.cn/codeNorms/201502275.asp