目的
為了規范代碼庫分支管理 和 版本管理，使代碼分支及版本結構清晰，方便維護，並避免由於維護造成的錯誤的版本發布等問題。
適用范圍
適用於Lifeix所以項目。
規范
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分支
使用規范：
-
- 可以從develop分支派生
- 必須合並回develop分支和master分支
- 分支命名慣例：
release-*
release分支是為發布新的產品版本而設計的。在這個分支上的代碼允許做小的缺陷修正、准備發布版本所需的各項說明信息（版本號、發布時間、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代周期。
當develop分支上的代碼已經包含了所有即將發布的版本中所計划包含的軟件功能，並且已通過所有測試時，我們就可以考慮准備創建release分支了。而所有在當前即將發布的版本之外的業務需求一定要確保不能混到release分支之內（避免由此引入一些不可控的系統缺陷）。
成功的派生了release分支，並被賦予版本號之后，develop分支就可以為“下一個版本”服務了。所謂的“下一個版本”是在當前即將發布的版本之后發布的版本。版本號的命名可以依據項目定義的版本號命名規則進行。
hotfix分支
使用規范：
-
- 可以從master分支派生
- 必須合並回master分支和develop分支
- 分支命名慣例：
hotfix-*
除了是計划外創建的以外，hotfix分支與release分支十分相似：都可以產生一個新的可供在生產環境部署的軟件版本。當生產環境中的軟件遇到了異常情況或者發現了嚴重到必須立即修復的軟件缺陷的時候，就需要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工作。
feature分支
使用規范：
-
- 可以從develop分支發起feature分支
- 代碼必須合並回develop分支
- 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版本的。