王曉龍,董玉雪

（中國海洋大學(xué) 基礎(chǔ)教學(xué)中心,青島 266100）

代碼管理在軟件發(fā)展過程中扮演者至關(guān)重要的角色,也是衡量軟件開發(fā)過程的一個重要指標(biāo),已經(jīng)被越來越多的企業(yè)所重視.隨著軟件需求和功能越來越復(fù)雜,對于代碼管理的要求也越來越高,良好的代碼管理可以提高整體開發(fā)效率,及時暴露問題[1,2].

分支管理是代碼管理過程中最常用的操作,也是最容易出錯的環(huán)節(jié)[3,4],目前的代碼分支管理更多的是利用Git或者SVN等成熟的版本控制工具進(jìn)行維護(hù),隨著軟件的功能和版本越來越復(fù)雜,代碼分支的數(shù)量日益增多,開發(fā)人員在代碼提交過程中難以保證分支代碼的一致性,日趨復(fù)雜的軟件開發(fā)活動給代碼分支管理帶來巨大的挑戰(zhàn),多分支代碼漏合[5,6]問題也應(yīng)運而生,嚴(yán)重影響了軟件開發(fā)效率[2,7].為了更好的推動代碼分支管理,支撐軟件開發(fā)過程的快速有序進(jìn)行,越來越多的公司已經(jīng)對代碼分支管理進(jìn)行了深入的研究,伴隨著出現(xiàn)了許多代碼分支管理模型[3],例如FaceBook采用的主干開發(fā),主干發(fā)布模型,以單一主干分支支撐開發(fā)過程; Qunar、豬齒魚、阿里云效平臺采用的分支開發(fā),主干發(fā)布模型,將代碼的開發(fā)與發(fā)布過程通過分支進(jìn)行劃分.代碼分支管理模型制定了代碼管理規(guī)范,優(yōu)化了代碼提交過程,對于提高軟件開發(fā)效率具有重要的作用.

雖然已有的代碼分支管理模型可以提高軟件開發(fā)的效率,但如果在實際應(yīng)用中缺乏系統(tǒng)的管理,依然會存在很多問題.本文以Git版本管理工具作為研究對象[8],對開發(fā)過程中常用的代碼分支管理模式進(jìn)行了研究分析,并基于分支開發(fā)、分支發(fā)布模式對多分支開發(fā)過程中的分支代碼漏合問題進(jìn)行了解決途徑研究.本文的研究問題來源于實際應(yīng)用場景,解決措施經(jīng)過了實踐的驗證,可以為多分支代碼管理的研究提供一定的參考.

1 多分支代碼漏合問題

多分支代碼管理是軟件開發(fā)過程中的重要活動,對于提高軟件開發(fā)效率和軟件質(zhì)量有重要的作用[9],做好代碼分支管理是軟件開發(fā)過程正常進(jìn)行的有效保障[1,6].由于代碼開發(fā)過程的日趨復(fù)雜,多分支并行開發(fā)過程容易出現(xiàn)分支間代碼漏合問題且不易排查,代碼漏合問題主要是由如下幾個方面導(dǎo)致的.

1.1 分支操作權(quán)限混亂

代碼分支的操作權(quán)限缺乏統(tǒng)一的管理,分支的創(chuàng)建、刪除、合并等權(quán)限如果沒有按照等級分類進(jìn)行分配,開發(fā)人員在自主創(chuàng)建代碼分支時容易導(dǎo)致多個重復(fù)分支的出現(xiàn),致使分支管理過程中出現(xiàn)代碼相互覆蓋、分支操作混亂等問題[5,10],最終導(dǎo)致未經(jīng)驗證的代碼直接流入生產(chǎn)環(huán)境.

1.2 分支管理缺乏規(guī)范

分支管理缺乏規(guī)范的指導(dǎo),包括分支命名存在二義性、分支與代碼版本缺少對應(yīng)關(guān)系,容易導(dǎo)致代碼提交過程混亂,出現(xiàn)代碼提交分支錯誤[6,10]和無法對歷史代碼及版本進(jìn)行追溯等問題,增加了分支維護(hù)的難度[2,4,11].

1.3 分支合并流程混亂

分支代碼漏合主要是多分支并行開發(fā)過程中對于分支合并操作缺乏規(guī)范的操作流程,導(dǎo)致代碼合并時出現(xiàn)遺漏的現(xiàn)象,致使發(fā)布到生產(chǎn)環(huán)境中的軟件功能不全.常見的多分支開發(fā)場景及分支合并流程如圖1所示,代碼開發(fā)過程中新分支的創(chuàng)建可能來源于master分支上,也可能來源于已有的feature分支,每個分支負(fù)責(zé)一個feature功能開發(fā),進(jìn)行版本發(fā)布時需要將該分支的代碼合入到master分支中,版本發(fā)布后需要將master分支的最新代碼合入到其他的feature分支中,以保證feature分支中的代碼最全,可以避免后續(xù)分支版本發(fā)布時的代碼遺漏現(xiàn)象.

圖1 多分支并行開發(fā)場景

2 代碼分支管理模式

軟件開發(fā)過程中的代碼管理一般是基于代碼分支管理模式進(jìn)行的,代碼分支管理模式可以規(guī)范代碼分支的管理過程,在一定程度上減少分支管理和維護(hù)的成本,有利于保證代碼分支管理的有序進(jìn)行.

不同的軟件開發(fā)場景所采用的代碼分支管理模式不盡相同,本文就以下幾種常用的代碼分支管理模式進(jìn)行了調(diào)研和分析,并闡述了各個模式的優(yōu)缺點和適用的開發(fā)場景.

2.1 主干開發(fā),主干發(fā)布:M-M

主干開發(fā)、主干發(fā)布模式只有一條主干分支,所有的代碼提交和Bug修復(fù)都在主干分支上進(jìn)行,提交的內(nèi)容可以從主干分支上直接發(fā)布到生產(chǎn)環(huán)境,如圖2所示.

圖2 主干開發(fā)、主干發(fā)布模式

主干提交、主干發(fā)布的模式只有一個分支,在實際開發(fā)實踐中存在如下幾點優(yōu)勢:1）迭代極快,隨時可發(fā)布; 2）沒有分支合并的麻煩,不用擔(dān)心分支合并出錯.同時該模式的缺點也比較明顯:1）版本迭代過程中開發(fā)人員的協(xié)同難度大; 2）版本發(fā)布頻率取決于主干分支的代碼質(zhì)量和穩(wěn)定性; 3）頻繁的代碼提交使得主干分支的壓力較大,需要具備較為完備的代碼提交標(biāo)準(zhǔn).

該模式對于分支的維護(hù)較為簡潔,可以減少多分支管理的成本,避免分支間代碼漏合的現(xiàn)象,但對于開發(fā)人員的能力要求較高,開發(fā)人員本身要具備保證分支版本一致性的能力和意識.

2.2 主干開發(fā),分支發(fā)布:M-B

主干開發(fā)、分支發(fā)布模式要求項目團(tuán)隊都在一個主干上進(jìn)行版本開發(fā),只有在需要發(fā)布時拉取新的分支,并在新分支上進(jìn)行缺陷的修復(fù),如圖3所示.

圖3 主干開發(fā)、分支發(fā)布模式

主干開發(fā),分支發(fā)布模式是以發(fā)布為目的創(chuàng)建短期分支,新創(chuàng)建的分支僅僅用來版本發(fā)布,生命周期比較短,發(fā)布結(jié)束之后都要回歸主干分支.其優(yōu)勢主要有:1）只有一條主干分支,保證了代碼的唯一性; 2）主干分支永久存在,開發(fā)過程比較平穩(wěn); 3）版本發(fā)布過程以版本號來規(guī)范分支創(chuàng)建,便于統(tǒng)計維護(hù).同時該模式也存在如下缺點:1）對主干分支要求很高,主干分支不穩(wěn)定容易導(dǎo)致發(fā)布分支難產(chǎn); 2）主干分支質(zhì)量決定版本發(fā)布頻率; 3）頻繁的代碼提交容易導(dǎo)致版本發(fā)布的節(jié)點不易把控.

M-B模式可以看作是M-M模式的延伸,可以保證主干開發(fā)的延續(xù)性和版本的正常發(fā)布,適用于頻發(fā)發(fā)布為主的代碼開發(fā)模式.

2.3 分支開發(fā),主干發(fā)布:B-M

分支開發(fā),主干發(fā)布模式允許系統(tǒng)工程師根據(jù)系統(tǒng)功能創(chuàng)建分支,并在功能開發(fā)完成后合并到主分支,最后將特性分支刪除,如圖4所示.

圖4 分支開發(fā)、主干發(fā)布模式

分支開發(fā),主干發(fā)布模式的優(yōu)勢主要有:1）特性分支相互獨立,開發(fā)過程互不干擾; 2）分支和功能特性相對應(yīng),版本功能迭代方便,便于維護(hù)和追溯.其缺點主要有:1）分支按照功能特性創(chuàng)建,一個特性只關(guān)聯(lián)一個分支,考驗開發(fā)人員的特性拆分能力; 2）分支命名規(guī)范嚴(yán)格,否則不利于分支的統(tǒng)一管理.

B-M管理模式是基于軟件的功能特性,以快速交付為目的,適用于版本迭代快速的敏捷開發(fā)場景.

2.4 分支開發(fā),分支發(fā)布:B-B

分支開發(fā),分支發(fā)布模式中開發(fā)人員在特性分支上進(jìn)行功能開發(fā),并從中發(fā)布版本,然后在發(fā)布后將代碼合并回主線分支,如圖5所示.

圖5 分支開發(fā)、分支發(fā)布模式

分支開發(fā)、分支發(fā)布模式的優(yōu)勢包括:1）主干分支長期穩(wěn)定存在,代碼維護(hù)較為統(tǒng)一; 2）特定分支單獨維護(hù),不同分支的版本發(fā)布相對獨立.其缺點為:1）特性分支過多,不同分支的版本維護(hù)比較混亂,容易出現(xiàn)分支漏合的現(xiàn)象; 2）各個分支單獨維護(hù),很難做到分支的統(tǒng)一管理.

B-B模式中主干分支用于代碼同步,多條特性分支并存,不同分支的代碼迭代相對獨立,適用于多項目、多版本的并行開發(fā)場景.

2.5 分支管理模式選擇

每種分支管理模式都有其特點和應(yīng)用場景,就通用特點而言,M-M模式適用于需求功能較為簡單且版本發(fā)布有先后順序開發(fā)場景; M-B模式適用于單一功能版本的串行開發(fā)場景; B-M模式適用于功能緊湊、版本迭代快速的敏捷開發(fā)場景; B-B模式適用于功能相對獨立的多版本的并行開發(fā)場景.

相對于其他3種分支管理模式而言,B-B模式中分支單獨維護(hù),相互間的影響較小,分支的生命周期維護(hù)清晰明確,對于版本并行開發(fā)和發(fā)布以及功能的追溯比較容易實現(xiàn),可以更好的支持多項目、多版本的并行開發(fā)[8],所以本文主要基于B-B模式對多分支代碼漏合問題進(jìn)行了解決途徑的研究.

3 多分支代碼漏合的解決途徑

本文結(jié)合了企業(yè)工作中的代碼管理經(jīng)驗,基于分支開發(fā)、分支發(fā)布管理模式對分支代碼漏合問題進(jìn)行了解決途徑研究,主要包括分支操作權(quán)限規(guī)范、分支管理規(guī)范和多分支代碼合并規(guī)范3個方面的內(nèi)容.

B-B模式中分支管理過程如圖6所示,所有分支的創(chuàng)建都以master分支為來源,不同分支單獨開發(fā)維護(hù),當(dāng)master分支有新版本代碼合入時需要同步將maser分支最新代碼merge到其他特性分支中,以保證特性分支的代碼是最新的,可以避免后續(xù)的版本發(fā)布過程出現(xiàn)代碼遺漏現(xiàn)象; 任意特性分支在版本發(fā)布之后將當(dāng)前分支代碼合入到master分支中并將當(dāng)前分支刪除,保證master分支始終包含所有的功能代碼;master分支代碼更新之后同步將當(dāng)前最新代碼merge到其他的特性分支中,并繼續(xù)開展后續(xù)的版本開發(fā)工作.

圖6 分支開發(fā)、主干發(fā)布管理模式

3.1 規(guī)范分支操作權(quán)限

對于分支操作的權(quán)限分配應(yīng)該由配置管理團(tuán)隊統(tǒng)一管理,不同級別的開發(fā)人員具有不同的分支操作權(quán)限,普通開發(fā)者只有分支代碼提交和代碼評審權(quán)限,系統(tǒng)工程師負(fù)責(zé)分支的具體維護(hù),包括分支的創(chuàng)建、刪除、合并等操作[12].

分支操作權(quán)限的分配可以規(guī)范開發(fā)人員的代碼操作過程,權(quán)限的合理分配可以減少分支合并過程中的問題,保證分支管理的有序進(jìn)行.

3.2 規(guī)范分支管理過程

分支管理規(guī)范的制定可以標(biāo)準(zhǔn)化分支管理過程,降低分支維護(hù)的難度,主要包括分支命名、分支創(chuàng)建來源和分支生命周期維護(hù)等幾個方面.

1）分支命名.分支命名采用版本化處理,與代碼版本進(jìn)行邏輯綁定,確保分支與代碼功能的可追溯性.分支的命名可以采用“分支類型_版本號”的形式,例如版本1.0.0的開發(fā)分支可命名為:dev_1.0.0,既可以實現(xiàn)分支和版本的對應(yīng)關(guān)系,又使得分支維護(hù)更加清晰.

2）分支創(chuàng)建來源.根據(jù)B-B分支管理模式,所有的分支的創(chuàng)建都來源于master分支,并且需要系統(tǒng)工程師根據(jù)版本功能進(jìn)行分支整體規(guī)劃,以保證分支代碼來源的一致性和規(guī)范性,避免后續(xù)分支代碼合入的過程中出現(xiàn)混亂情況[13].以master分支創(chuàng)建特性分支dev_1.0.0為例,具體實現(xiàn)過程如下:

//將project項目clone到本地

git clone project

//切換到項目的master分支

git checkout master

//創(chuàng)建本地dev_1.0.0分支

git branch dev_1.0.0

//將本地分支推送到遠(yuǎn)程倉庫中

git push-u origin dev_1.0.0

3）分支生命周期維護(hù).代碼開發(fā)之前系統(tǒng)工程師提前規(guī)劃代碼版本并創(chuàng)建特性分支,將代碼提交分支通知到開發(fā)人員,避免代碼提交時分支選擇錯誤; 版本發(fā)布時系統(tǒng)工程師進(jìn)行分支合并及tag版本發(fā)布; 代碼發(fā)布上線之后,系統(tǒng)工程師將對應(yīng)的特性分支刪除,避免歷史遺留分支影響代碼提交過程.

3.3 規(guī)范多分支代碼合并過程

代碼分支間漏合問題主要是分支合并時操作不規(guī)范導(dǎo)致分支代碼遺漏,在B-B模式中主要的漏合場景是master分支已經(jīng)合入了新的功能代碼,而未將master分支最新代碼merge到其他特性分支中,導(dǎo)致后續(xù)特性分支在進(jìn)行版本發(fā)布時代碼不全,出現(xiàn)分支代碼漏合現(xiàn)象,主要的解決措施有如下幾個.

3.3.1 增加分支漏合檢測機(jī)制

在B-B模式中,由于所有的特性分支都來源于master分支,所以針對代碼分支間漏合問題,增加代碼一致性檢測機(jī)制,在分支代碼開發(fā)過程中通過命令git merge-base判斷當(dāng)前分支與master分支的最新代碼是否同步.

1）分支同步檢測機(jī)制

開發(fā)人員進(jìn)行提交代碼時,觸發(fā)分支代碼同步檢測算法,檢測當(dāng)前分支的來源commitid是否和master分支最新的commitid保持同步,如果不同步則代表master分支的代碼優(yōu)先于當(dāng)前開發(fā)分支,即master分支合入了新的代碼,需要將master分支的代碼merge到當(dāng)前分支之后再進(jìn)行后續(xù)的開發(fā),否則版本發(fā)布時容易出現(xiàn)代碼漏合現(xiàn)象.

2）分支同步檢測算法

以master分支和dev_1.0.0分支為例,分支同步檢測算法的執(zhí)行過程如下所示.

分支同步檢測過程分為3個步驟:

（1）執(zhí)行命令git rev-parse HEAD分別獲取dev_1.0.0分支和master分支最新的commitid.

（2）利用git merge-base命令獲取分支同步檢測結(jié)果.例如:dev_1.0.0分支最新的commtid是 f5c67f88fc,master分支最新的commtid是a1e2dee286,執(zhí)行命令git merge-base f5c67f88fc a1e2dee286查看返回結(jié)果.

（3）判斷分支代碼是否同步,如果git merge-base命令返回的是master的commitid:a1e2dee286,則表示當(dāng)前分支已經(jīng)同步了master分支的最新代碼,否則代表分之間代碼尚未同步.

3.3.2 規(guī)范多分支并行開發(fā)流程

代碼開發(fā)過程中由于版本迭代頻繁,開發(fā)人員通常需要在多個分支上進(jìn)行功能開發(fā),且每次代碼提交的Patch在review階段需要一定的周期,根據(jù)實際的開發(fā)經(jīng)驗,多分支開發(fā)過程可以按照如圖7所示的流程進(jìn)行,以避免分支代碼提交過程混亂.

圖7 多分支開發(fā)流程圖

1）master分支只用來同步分支代碼,開發(fā)過程中不進(jìn)行任何代碼提交操作.

2）版本功能的開發(fā)在特性分支上完成,分支A進(jìn)行A功能的開發(fā),分支B進(jìn)行B功能的開發(fā).

3）分支A進(jìn)行代碼review時暫停A功能的開發(fā),然后同步在B分支上進(jìn)行功能B的開發(fā); A分支代碼review結(jié)束之后,暫存B分支的開發(fā)任務(wù),結(jié)合分支A的review結(jié)果進(jìn)行代碼修改及后續(xù)的代碼開發(fā);同樣的在B分支進(jìn)行代碼review時,暫停B功能的開發(fā)并同步進(jìn)行A分支的代碼開發(fā)工作,以此不斷交替進(jìn)行.

4）當(dāng)分支A代碼合入到master分支后即可刪掉,同步更新master分支最新代碼到B分支上.

5）以此循環(huán)往復(fù)不斷重復(fù)以上步驟.

4 解決途徑結(jié)果驗證

多分支代碼漏合問題的解決措施已經(jīng)基于分支開發(fā)、分支發(fā)布模式應(yīng)用到了實踐中,本文主要就分支操作權(quán)限和多分支漏合檢測機(jī)制兩個方面進(jìn)行了驗證結(jié)果的相關(guān)描述.

4.1 分支操作權(quán)限驗證

分支權(quán)限管理依托Gerrit開源工具的支持,所有代碼及分支的操作權(quán)限都通過Gerrit權(quán)限機(jī)制實現(xiàn).如圖8所示的部分權(quán)限規(guī)劃內(nèi)容,通過對不同的人員進(jìn)行分組,然后對組實現(xiàn)權(quán)限劃分.分支創(chuàng)建權(quán)限交由Project Owners群組; 代碼review權(quán)限按照操作權(quán)限等級分配給不同的開發(fā)者,從而達(dá)到權(quán)限控制的效果.

圖8 部分權(quán)限規(guī)劃內(nèi)容

以代碼review操作為例,普通的開發(fā)者只有提交代碼和代碼review+1的權(quán)限,代碼+2和分支合并等權(quán)限由更高級別的系統(tǒng)工程師完成,Gerrit中的實現(xiàn)效果如圖9所示.

圖9 代碼review權(quán)限劃分效果

4.2 多分支漏合檢測機(jī)制驗證

分支漏合檢測機(jī)制在每次代碼提交之后執(zhí)行,可以及早的發(fā)現(xiàn)問題,縮小問題的影響范圍.本文的分支漏合檢測機(jī)制通過Jenkins調(diào)度執(zhí)行,Jenkins的CI流程通過監(jiān)聽Git倉庫的代碼變更,然后從遠(yuǎn)程倉庫中克隆代碼并執(zhí)行對應(yīng)的檢測算法.Jenkins的具體執(zhí)行效果如圖10所示,分別獲取當(dāng)前分支和master分支的commit_id,然后通過判斷git merge-base的檢測結(jié)果來驗證分支代碼是否同步.

圖10 Jenkins分支合并檢測

5 小結(jié)

本文針對常見的代碼分支管理模式進(jìn)行了研究與分析,并基于分支開發(fā)、分支發(fā)布模型對多分支代碼漏合問題進(jìn)行了解決途徑的探討和研究.本文探討的問題源于實踐開發(fā)經(jīng)驗,具有實際的解決意義,同時解決措施也進(jìn)行了實踐的驗證,可以為代碼分支管理的研究提供一定的參考; 但相對于分支管理功能較為完善的大公司來說,尚缺乏統(tǒng)一直觀的管理平臺對分支進(jìn)行跟蹤與維護(hù),仍需要進(jìn)行不斷的完善和改進(jìn).