超實用的代碼版本管理規(guī)范流程

作者：Gitee 2020-09-28 12:39:44

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

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

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

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

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

代碼庫分類

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

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

人員角色分類

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

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

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

基本流程

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

分支管理

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

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

常見問題

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

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

產生原因

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

解決方法

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

責任編輯：未麗燕來源：今日頭條