版本管理(Revision control)是一種軟件工程方法，在開發的過程中，確保由不同開發人員編輯的同一檔案都得到更新。代碼版本管理其實就是我們在日常的開發過程中，將每天、每個階段、每個功能等要求完成之后，將我們的代碼再提供給他人的一種行為。

這個行為的目的就是，讓每一個人的開發過程都有據可查，最后實現多人合作開發的目的。

目前市面上比較流行的是通過 Git 進行代碼版本管理，因為它易于學習，占用內存小，具有閃電般快速的性能，

規范且流程化的版本管理，不僅能有效的提升代碼質量，而且還能幫助項目團隊有序協同，輕松提升研發效能，那么Git 代碼版本管理的規范化流程有哪些呢?

基于 Git 的代碼版本管理主要包括：代碼庫的分布、人員角色的劃分、代碼提交合并流程、代碼沖突處理、分支管理。

代碼庫分類

根據代碼庫分布的位置及作用，分為以下幾類：

• 主倉庫：位于服務端，所有開發的代碼最終都要合到主倉庫。
• 個人代碼庫(服務端)：從主倉庫 fork 出來，位于服務端。每個人自已開發的代碼，由本地的 Git 庫 push 到每個人自己的個人代碼庫(服務端)，再由個人代碼庫(服務端)合入主倉庫。
• 個人工作庫：位于每個開發人員的開發機器，從個人代碼庫(服務端)clone 到本地。每個開發人員開發的代碼，先 commit 到個人工作庫，再由個人工作庫 push 到個人代碼庫(服務端)。

人員角色分類

這里說的角色，都是人員在主倉庫上的角色。基于簡化的原則，人員分為三類：

• Owner：擁有主倉庫的所有權限。
• Committer：具有將開發人員的合并需求(PR)合入主倉庫的權限。基于安全考慮，我們設置為只能通過 PR 的方式將代碼合入主倉庫，而不能直接 push 到主倉庫。
• Developer：只能從自己的個人代碼庫(服務端)提交合并代碼的請求(PR)，是否能夠合入，由 Committer 進行審核。

以 Gitee 企業版為例，Developer 進行 PR 后有權限的 Committer 需要對代碼進行審查，審查通過后方可進行合并。

基本流程

在主倉庫已經存在的情況下，日常操作流程如下：

• 開發人員從主倉庫 fork 出自己的個人代碼庫。
• 開發人員將自己的個人代碼庫 clone 到本地，即個人工作庫。
• 開發人員在開發了新代碼后(包括新增和修改)，先將代碼 commit 到自己的個人工作庫，再由個人工作庫 push 到個人代碼庫。
• 開發人員提交從個人工作庫到主倉庫的 PR，Committer 審核后，決定是否將 PR 合入主倉庫。
• 每個開發人員從主倉庫 pull 最新代碼到個人工作庫。

分支管理

• 主倉庫缺省的 master 分支，是用來向生產環境發布的，所有合入的代碼，原則上都必須是穩定的。
• 主倉庫除了 master 分支外，至少還要有一個活動分支，命名建議為：br_工程名_active，平時日常的開發都基于活動分支開發。即從個人工作庫提交 PR 到主倉庫時，指向的是主倉庫的活動分支。活動分支測試穩定后，將主倉庫的活動分支通過 PR 的形式，合并到主倉庫的 master 分支，同時打上 tag。
• 如果軟件運行過程中發現必須立即修改的 Bug，則從主倉庫的 master 分支中，拉出一個 bugfix 分支。為修復這個 Bug 的所有開發，都基于 bugfix 分支。待 bugfix 分支開發完成，并測試穩定后，將 bugfix 分支以 PR 的方合入主倉庫的 master 分支。然后刪除 bugfix 分支，視情況決定是否打 tag。
• 在生產開發協作的實際過程中，出于內部控制的考量，往往需要自定義擁有某些關鍵分支推送(push)和合并(merge)權限的人群。

以 Gitee企業版為例，可以采用「分支狀態」中的「保護分支」功能。被設為保護分支之后，該分支只允許對應的「保護分支規則」內選中的倉庫成員對此分支進行合并/推送操作。

常見問題

此部分內容會根據情況進行相應的增加。

活動分支合入主分支時發生沖突

產生原因

平時基于活動分支開發，如果這個過程中為了修復 Bug 而拉了一個 bugfix 分支，當 bugfix 分支開發完成并合入 master 分支后，如果 bugfix 分支和活動分支修改了相同的文件，則在活動分支合入 master 分支時就會產生沖突。

解決方法

1. 從個人代碼庫(服務端)clone 一個庫到本地，即專門用于合并的個人工作庫。(也可以用之前的個人工作庫，但初學都容易混淆，建議單獨 clone 一個。)
2. 從主倉庫的活動分支上 pull 最新的代碼到本地。
3. 從主倉庫的 master 分支上 pull 最新的代碼到本地。
4. 此時會產生沖突，手工修復沖突，然后先 commit 到本地的個人工作庫，再 push 到個人代碼庫(服務端)。
5. 提交從個人工作庫(服務端)到主倉庫的 PR(此時不會再有沖突)，然后由 Committer 審核后將PR合入主倉庫。

不單是在研發團隊的工作中，在開源項目中也同樣需要規范的版本管理。而對初學者而言，我們建議在開始進行實踐小項目的階段即進行規范的版本管理，因為在以后的工作中代碼版本管理將會是一項非常重要的技能。