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

這個行為的目的就是，讓每一個人的開發(fā)過程都有據(jù)可查，最后實現(xiàn)多人合作開發(fā)的目的。

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

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

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

代碼庫分類

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

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

人員角色分類

這里說的角色，都是人員在主倉庫上的角色?；诤喕脑瓌t，人員分為三類：

• Owner：擁有主倉庫的所有權(quán)限。
• Committer：具有將開發(fā)人員的合并需求(PR)合入主倉庫的權(quán)限?；诎踩紤]，我們設(shè)置為只能通過 PR 的方式將代碼合入主倉庫，而不能直接 push 到主倉庫。
• Developer：只能從自己的個人代碼庫(服務(wù)端)提交合并代碼的請求(PR)，是否能夠合入，由 Committer 進行審核。

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

基本流程

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

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

分支管理

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

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

常見問題

此部分內(nèi)容會根據(jù)情況進行相應(yīng)的增加。

活動分支合入主分支時發(fā)生沖突

產(chǎn)生原因

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

解決方法

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

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