Git分支管理的策略梳理

轉(zhuǎn)載:Git分支管理的策略梳理

當(dāng)下最流行的版本管理系統(tǒng)應(yīng)該是非Git莫屬。相比同類軟件,Git有很多優(yōu)點(diǎn),其中很顯著的一點(diǎn),就是版本的分支(branch)和合并(merge)十分方便。有些傳統(tǒng)的版本管理軟件,分支操作實(shí)際上會(huì)生成一份現(xiàn)有代碼的物理拷貝,而Git只生成一個(gè)指向當(dāng)前版本(又稱"快照")的指針,因此非??旖菀子谩5?,太方便了也會(huì)產(chǎn)生副作用。如果不加注意,很可能會(huì)留下一個(gè)枝節(jié)蔓生、四處開放的版本庫,到處都是分支,完全看不出主干發(fā)展的脈絡(luò)。Vincent Driessen提出了一個(gè)分支管理的策略,非常值得借鑒!它可以使得版本庫的演進(jìn)保持簡(jiǎn)潔,主干清晰,各個(gè)分支各司其職、井井有條。
下面就對(duì)這一策略做一簡(jiǎn)單梳理:

1)主分支Master

首先,代碼庫應(yīng)該有一個(gè)、且僅有一個(gè)主分支。所有提供給用戶使用的正式版本,都在這個(gè)主分支上發(fā)布。
Git主分支的名字,默認(rèn)叫做Master。它是自動(dòng)建立的,版本庫初始化以后,默認(rèn)就是在主分支在進(jìn)行開發(fā)。

2)開發(fā)分支Develop

主分支只用來分布重大版本,日常開發(fā)應(yīng)該在另一條分支上完成。我們把開發(fā)用的分支,叫做Develop。
這個(gè)分支可以用來生成代碼的最新隔夜版本(nightly)。如果想正式對(duì)外發(fā)布,就在Master分支上,對(duì)Develop分支進(jìn)行"合并"(merge)。
Git創(chuàng)建Develop分支的命令:
# git checkout -b develop master
將Develop分支發(fā)布到Master分支的命令:
切換到Master分支
# git checkout master
對(duì)Develop分支進(jìn)行合并
# git merge --no-ff develop

上面命令中的--no-ff參數(shù)是什么意思。默認(rèn)情況下,Git執(zhí)行"快進(jìn)式合并"(fast-farward merge),會(huì)直接將Master分支指向Develop分支。
使用--no-ff參數(shù)后,會(huì)執(zhí)行正常合并,在Master分支上生成一個(gè)新節(jié)點(diǎn)。為了保證版本演進(jìn)的清晰,我們希望采用這種做法。

3)臨時(shí)性分支

前面講到版本庫的兩條主要分支:Master和Develop。前者用于正式發(fā)布,后者用于日常開發(fā)。其實(shí),常設(shè)分支只需要這兩條就夠了,不需要其他了。
但是,除了常設(shè)分支以外,還有一些臨時(shí)性分支,用于應(yīng)對(duì)一些特定目的的版本開發(fā)。臨時(shí)性分支主要有三種:

1)功能(feature)分支
2)預(yù)發(fā)布(release)分支
3)修補(bǔ)bug(fixbug)分支

這三種分支都屬于臨時(shí)性需要,使用完以后,應(yīng)該刪除,使得代碼庫的常設(shè)分支始終只有Master和Develop。

3.1)功能分支

接下來,一個(gè)個(gè)來看這三種"臨時(shí)性分支"。
第一種是功能分支,它是為了開發(fā)某種特定功能,從Develop分支上面分出來的。開發(fā)完成后,要再并入Develop。
功能分支的名字,可以采用feature-*的形式命名。

創(chuàng)建一個(gè)功能分支:
# git checkout -b feature-x develop

開發(fā)完成后,將功能分支合并到develop分支:
# git checkout develop
# git merge --no-ff feature-x

刪除feature分支:
# git branch -d feature-x

3.2)預(yù)發(fā)布分支

第二種是預(yù)發(fā)布分支,它是指發(fā)布正式版本之前(即合并到Master分支之前),我們可能需要有一個(gè)預(yù)發(fā)布的版本進(jìn)行測(cè)試。
預(yù)發(fā)布分支是從Develop分支上面分出來的,預(yù)發(fā)布結(jié)束以后,必須合并進(jìn)Develop和Master分支。它的命名,可以采用release-*的形式。

創(chuàng)建一個(gè)預(yù)發(fā)布分支:
# git checkout -b release-1.2 develop

確認(rèn)沒有問題后,合并到master分支:
# git checkout master
# git merge --no-ff release-1.2

對(duì)合并生成的新節(jié)點(diǎn),做一個(gè)標(biāo)簽
# git tag -a 1.2

再合并到develop分支:
# git checkout develop
# git merge --no-ff release-1.2

最后,刪除預(yù)發(fā)布分支:
# git branch -d release-1.2

3.3)修補(bǔ)bug分支

最后一種是修補(bǔ)bug分支。軟件正式發(fā)布以后,難免會(huì)出現(xiàn)bug。這時(shí)就需要?jiǎng)?chuàng)建一個(gè)分支,進(jìn)行bug修補(bǔ)。
修補(bǔ)bug分支是從Master分支上面分出來的。修補(bǔ)結(jié)束以后,再合并進(jìn)Master和Develop分支。它的命名,可以采用fixbug-*的形式。

創(chuàng)建一個(gè)修補(bǔ)bug分支:
# git checkout -b fixbug-0.1 master

修補(bǔ)結(jié)束后,合并到master分支:
# git checkout master
# git merge --no-ff fixbug-0.1
# git tag -a 0.1.1

再合并到develop分支:
# git checkout develop
# git merge --no-ff fixbug-0.1

最后,刪除"修補(bǔ)bug分支":
# git branch -d fixbug-0.1

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 如果你嚴(yán)肅對(duì)待編程,就必定會(huì)使用"版本管理系統(tǒng)"(Version Control System)。 眼下最流行的"...
    木易林1閱讀 593評(píng)論 1 0
  • 眼下最流行的”版本管理系統(tǒng)”,非Git莫屬。 相比同類軟件,Git有很多優(yōu)點(diǎn)。其中很顯著的一點(diǎn),就是版本的分支(b...
    零一間閱讀 454評(píng)論 0 2
  • git分支使用的壞習(xí)慣 最近使用git提交代碼發(fā)現(xiàn)大家的方式都不一樣,自己在使用中也遇到了一些問題,導(dǎo)致代碼危險(xiǎn)。...
    好奇的小刺猬閱讀 1,816評(píng)論 0 1
  • 有時(shí)候碰到傻逼限于各種情況你沒辦法反駁是最憋屈的
    Scandal閱讀 241評(píng)論 0 0
  • 冷風(fēng)陣陣吹面寒,夕輝束束照胸暖。幾只喜鵲歸巢去,一縷霞光灑天際。
    德惠208張洪玲閱讀 126評(píng)論 0 0

友情鏈接更多精彩內(nèi)容