基于git的簡單實用的版本管理規(guī)范及流程，包括：代碼庫的分布、人員角色的劃分、代碼提交合并流程、代碼沖突處理、分支管理。
代碼庫分類
根據代碼庫分布的位置及作用，分為以下幾類：
- 主庫：位于服務端，所有開發(fā)的代碼最終都要合到主庫。
- 個人代碼庫（服務端）：從主庫fork出來，位于服務端。每個人自已開發(fā)的代碼，由本地的git庫push到每個人自己的個人代碼庫（服務端），再由個人代碼庫（服務端）合入主加。
- 個人工作庫：位于每個開發(fā)人員的開發(fā)機器，從個人代碼庫（服務端）clone到本地。每個開發(fā)人員開發(fā)的代碼，先commit到個人工作庫，再由個人工作庫push到個人代碼庫（服務端）。
人員角色分類
這里說的角色，都是人員在主庫上的角色?；诤喕脑瓌t，人員分為三類：
- Owner：擁有主庫的所有權限。
- Committer：具有將開發(fā)人員的合并需求（MR）合入主庫的權限。基于安全考慮，我們設置為只能通過MR的方式將代碼合入主庫，而不能直接push到主庫。
- Developer：只能從自己的個人代碼庫（服務端）提交合并代碼的請求（MR），是否能夠合入，由Committer進行審核。
基本流程
在主庫已經存在的情況下，日常操作流程如下：
- 開發(fā)人員從主庫fork出自己的個人代碼庫。
- 開發(fā)人員將自己的個人代碼庫clone到本地，即個人工作庫。
- 開發(fā)人員在開發(fā)了新代碼后（包括新增和修改），先將代碼commit到自己的個人工作庫，再由個人工作庫push到個人代碼庫。
- 開發(fā)人員提交從個人工作庫到主庫的MR，Committer審核后，決定是否將MR合入主庫。
- 每個開發(fā)人員從主庫pull最新代碼到個人工作庫。
分支管理
- 主庫缺省的master分支，是用來向生產環(huán)境發(fā)布的，所有合入的代碼，原則上都必須是穩(wěn)定的。
- 主庫除了master分支外，至少還要有一個活動分支，命名建議為：br_工程名_active，平時日常的開發(fā)都基于活動分支開發(fā)。即從個人工作庫提交MR到主庫時，指向的是主庫的活動分支?；顒臃种y試穩(wěn)定后，將主庫的活動分支通過MR的形式，合并到主庫的master分支，同時打上tag。
- 如果軟件運行過程中發(fā)現必須立即修改的bug，則從主庫的master分支中，拉出一個bugfix分支。為修復這個bug的所有開發(fā)，都基于bugfix分支。待bugfix分支開發(fā)完成，并測試穩(wěn)定后，將bugfix分支以MR的方合入主庫的master分支。然后刪除bugfix分支，視情況決定是否打tag。
常見問題
此部分內容會根據情況進行相應的增加。
活動分支合入主分支時發(fā)生沖突
產生原因
平時基于活動分支開發(fā)，如果這個過程中為了修復bug而拉了一個bugfix分支，當bugfix分支開發(fā)完成并合入master分支后，如果bugfix分支和活動分支修改了相同的文件，則在活動分支合入master分支時就會產生沖突。
解決方法
- 從個人代碼庫（服務端）clone一個庫到本地，即專門用于合并的個人工作庫。（也可以用之前的個人工作庫，但初學都容易混淆，建議單獨clone一個。）
- 從主庫的活動分支上pull最新的代碼到本地。
- 從主庫的master分支上pull最新的代碼到本地。
- 此時會產生沖突，手工修復沖突，然后先commit到本地的個人工作庫，再push到個人代碼庫（服務端）。
- 提交從個人工作庫（服務端）到主庫的MR（此時不會再有沖突），然后由Committer審核后將MR合入主庫。
