基於git的簡單實用的版本管理規范及流程，包括：代碼庫的分布、人員角色的划分、代碼提交合並流程、代碼沖突處理、分支管理。
對於企業用戶，推薦使用CODING 企業版。
代碼庫分類
根據代碼庫分布的位置及作用，分為以下幾類：
- 主庫：位於服務端，所有開發的代碼最終都要合到主庫。
- 個人代碼庫（服務端）：從主庫fork出來，位於服務端。每個人自已開發的代碼，由本地的git庫push到每個人自己的個人代碼庫（服務端），再由個人代碼庫（服務端）合入主加。
- 個人工作庫：位於每個開發人員的開發機器，從個人代碼庫（服務端）clone到本地。每個開發人員開發的代碼，先commit到個人工作庫，再由個人工作庫push到個人代碼庫（服務端）。
人員角色分類
這里說的角色，都是人員在主庫上的角色。基於簡化的原則，人員分為三類：
- Owner：擁有主庫的所有權限。
- Committer：具有將開發人員的合並需求（MR）合入主庫的權限。基於安全考慮，我們設置為只能通過MR的方式將代碼合入主庫，而不能直接push到主庫。
- Developer：只能從自己的個人代碼庫（服務端）提交合並代碼的請求（MR），是否能夠合入，由Committer進行審核。
在CODING 企業版中，Committer在進行MR之前，可以對Developer提供的代碼進行review，輸入評審意見，並@給相關人員。
基本流程
在主庫已經存在的情況下，日常操作流程如下：
- 開發人員從主庫fork出自己的個人代碼庫。
- 開發人員將自己的個人代碼庫clone到本地，即個人工作庫。
- 開發人員在開發了新代碼后（包括新增和修改），先將代碼commit到自己的個人工作庫，再由個人工作庫push到個人代碼庫。
- 開發人員提交從個人工作庫到主庫的MR，Committer審核后，決定是否將MR合入主庫。
- 每個開發人員從主庫pull最新代碼到個人工作庫。
分支管理
- 主庫缺省的master分支，是用來向生產環境發布的，所有合入的代碼，原則上都必須是穩定的。
- 主庫除了master分支外，至少還要有一個活動分支，命名建議為：br_工程名_active，平時日常的開發都基於活動分支開發。即從個人工作庫提交MR到主庫時，指向的是主庫的活動分支。活動分支測試穩定后，將主庫的活動分支通過MR的形式，合並到主庫的master分支，同時打上tag。
- 如果軟件運行過程中發現必須立即修改的bug，則從主庫的master分支中，拉出一個bugfix分支。為修復這個bug的所有開發，都基於bugfix分支。待bugfix分支開發完成，並測試穩定后，將bugfix分支以MR的方合入主庫的master分支。然后刪除bugfix分支，視情況決定是否打tag。
在CODING 企業版中，合並分支的同時，可以選擇是否刪除源分支，十分方便。
常見問題
此部分內容會根據情況進行相應的增加。
活動分支合入主分支時發生沖突
產生原因
平時基於活動分支開發，如果這個過程中為了修復bug而拉了一個bugfix分支，當bugfix分支開發完成並合入master分支后，如果bugfix分支和活動分支修改了相同的文件，則在活動分支合入master分支時就會產生沖突。
解決方法
- 從個人代碼庫（服務端）clone一個庫到本地，即專門用於合並的個人工作庫。（也可以用之前的個人工作庫，但初學都容易混淆，建議單獨clone一個。）
- 從主庫的活動分支上pull最新的代碼到本地。
- 從主庫的master分支上pull最新的代碼到本地。
- 此時會產生沖突，手工修復沖突，然后先commit到本地的個人工作庫，再push到個人代碼庫（服務端）。
- 提交從個人工作庫（服務端）到主庫的MR（此時不會再有沖突），然后由Committer審核后將MR合入主庫。
CODING 企業版簡介
CODING企業版提供整套企業級的軟件研發管理系統，讓企業的管理人員可以更好地進⾏研發團隊的項⽬管理，便捷而深入地把握開發進度，讓開發流程⾼效可控。
CODING企業版從項⽬的管理，到代碼管理，直到代碼的推送和部署，CODING 企業版提供了一整套的完整解決方案。
企業管理
企業管理提供企業個性化定制、企業概覽和統計、項⽬及成員批量管理、項⽬權限一鍵開關、安全管理等一系列功能，可以滿足企業基本管理的需求。
項目管理
提供當前企業最前沿的敏捷開發，全生命周期項⽬和任務管理，幫助企業更好的管理項⽬和任務，以應對快速變化的IT項⽬管理需求。
- 簡潔高效的任務指派
- 雲端共享的項目文件
- 系統化的 Wiki 知識庫
- 多維度的項目統計
代碼管理
代碼管理提供以Git為基礎的日常開發源代碼版本管理，包括代碼瀏覽、分⽀管理、發布管理、版本對比、合並請求、項⽬⽹絡等，提供強於Git 的代碼管理使用體驗。
- 代碼倉庫
- 代碼評審
- 發布管理