一、目的
爲了減少在團隊協作開發時因分支管理不當而出現的代碼丟失、錯亂情況，需要一套標準規範來約定分支的相關操作；主要針對分支命名規範、分支操作流程進行說明
二、分支命名約定
-
master分支：公共分支，可以隨時編譯對外發布的穩定版本，不允許直接push 代碼，只接受feature/hotfix分支通過MR 操作合併代碼；當一個版本的所有功能再develop 測試通過後，在本地pull 拉取最新master 代碼，切換到開發feature分支，把master 分支merge 到 feature 分支（這一步一定要做，保證遠程MR一定會成功），把衝突在本地解決，之後把該分支push 到遠程，在遠程 通過MR 合併遠程master 分支，然後再更新本地master分支，並再本地打版本tag，再推送tag到遠程；
-
develop 分支：公共分支，該分支主要用於合併代碼並打包測試，而非功能開發，但不能合併到master； 禁止在該分支開發commit 代碼，只能通過feature分支在本地 merge 合併代碼，把衝突在本地解決，然後push到遠程；把feature分支合併develop 分支時，要先從服務端pull 一遍拉取最新代碼（有可能別人push了新的代碼），然後再進行本地merge 操作；
-
feature分支：獨立分支（命名以feature/function_desc），feature 分支主要用來開發功能，而非打包測試。開發完成之後，切到develop分支之後，按照develop 中的描述進行分支合併打包；Feature分支開發完成可以選擇刪除或者保留，feature分支的創建最好以功能特徵來命名，每一個功能對應一個feature分支，這樣做的好處就是代碼提交日誌清晰集中、功能並行開發切換自由；
-
hotfix分支: 獨立分支(命名以hotfix/開始)，一般用於修復已發佈版本的bug，直接從master上拉取。bug修復完成後，然後以feature 分支合併到master爲樣本，再操作一次 hotfix 分支即可。
總結：1. merge 操作之前，一定要pull 拉取當前分支的最新代碼；2. 解決代碼合併的衝突，一定是在本地進行的；3. 公共分支 不能進行commit操作，只能本地merge 或者遠程 merger （MR）來合併代碼 4. 每個分支都有一個 Life cycle ，下面我來一一解釋一下
三、流程圖
這裏爲了簡單起見，沒有創建release 分支，採用相對簡單的模式。
流程描述：
新功能開發
- 當我們需要開發新功能時，我們從最新的master 分支創建feature/function_desc 分支；
- 新功能開發完成時，把feature/function_desc 分支代碼合併到develop分支（注意：是develop merge feature，方向不能返了），然後進行提測；
- 測試通過後，把feature/function_desc 分支通過MR 合併到master分支，並再master分支標記tag；
- 再次開發新功能時，再重複步驟1即可
bug修復
- 對已經發布的master版本，突然線上發現問題了，需要再master tag1.0的基礎上拉取分支 hotfix/bugfix_login , 進行bug修復;
- bug修復完成，分支hotfix/bugfix_login 通過MR合併到master 分支；
循環新功能開發和bug修復兩個環節，就構成了我們日常開發基本流程，遵循上述步驟就可以避免因操作不當造成的各種問題，提升開發效率和滿足業務需求。
另外，如果想要掌握更全面的git 使用，要掌握git 的其他高級技能 變基 reBase 、stash 這些，可以查看git 教程官網。
