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

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

目前市面上比較流行的是通過(guò) Git 進(jìn)行代碼版本管理，因?yàn)樗子趯W(xué)習(xí)，占用內(nèi)存小，具有閃電般快速的性能，

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

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

代碼庫(kù)分類

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

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

人員角色分類

這里說(shuō)的角色，都是人員在主倉(cāng)庫(kù)上的角色?；诤?jiǎn)化的原則，人員分為三類：

• Owner：擁有主倉(cāng)庫(kù)的所有權(quán)限。
• Committer：具有將開(kāi)發(fā)人員的合并需求(PR)合入主倉(cāng)庫(kù)的權(quán)限。基于安全考慮，我們?cè)O(shè)置為只能通過(guò) PR 的方式將代碼合入主倉(cāng)庫(kù)，而不能直接 push 到主倉(cāng)庫(kù)。
• Developer：只能從自己的個(gè)人代碼庫(kù)(服務(wù)端)提交合并代碼的請(qǐng)求(PR)，是否能夠合入，由 Committer 進(jìn)行審核。

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

基本流程

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

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

分支管理

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

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

常見(jiàn)問(wèn)題

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

活動(dòng)分支合入主分支時(shí)發(fā)生沖突

產(chǎn)生原因

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

解決方法

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

不單是在研發(fā)團(tuán)隊(duì)的工作中，在開(kāi)源項(xiàng)目中也同樣需要規(guī)范的版本管理。而對(duì)初學(xué)者而言，我們建議在開(kāi)始進(jìn)行實(shí)踐小項(xiàng)目的階段即進(jìn)行規(guī)范的版本管理，因?yàn)樵谝院蟮墓ぷ髦写a版本管理將會(huì)是一項(xiàng)非常重要的技能。