天天看點

Git 分支管理是一門藝術

轉載: Git 分支管理是一門藝術

1

要確定:團隊成員從主分支(master)獲得的都是處于可釋出狀态的代碼,而從開發分支(develop)應該總能夠獲得最新開發進展的代碼。

2

“輔助分支”,大體包括如下幾類:“管理功能開發”的分支、“幫助建構可釋出代碼”的分支、“可以便捷的修複釋出版本關鍵BUG”的分支,

等等。

3

GIT,在技術層面上,絕對是一個無中心的分布式版本控制系統,但在管理層面上,我建議你保持一個中心版本庫。

Git 分支管理是一門藝術

4

我建議,一個中心版本庫(我們叫它origin)至少包括兩個分支,即“主分支(master)”和“開發分支(develop)”

Git 分支管理是一門藝術

5

在一個團隊開發協作中,我建議,要有“輔助分支”的概念。

6

“輔助分支”的最大特點就是“生命周期十分有限”,完成使命後即可被清除。

7

我建議至少還應設定三類“輔助分支”,我們稱之為“Feature branches”,“Release branches”,“Hotfix branches”。

至此,我們形成了如下這張最重要的組織組,包含了兩個粗體字分支(master/develop)和三個細體字分支(feature/release/hotfixes)。

Git 分支管理是一門藝術

8

“Feature branches”,起源于develop分支,最終也會歸于develop分支。

9

“Feature branches”常用于開發一個獨立的新功能,且其最終的結局必然隻有兩個,其一是合并入“develop”分支,其二是被抛棄。最典型的“Fearture branches”一定是存在于團隊開發者那裡,而不應該是“中心版本庫”中。

10

“Feature branches”起源于“develop”分支,實作方法是:

git checkout -b myfeature develop

11

“Feature branches”最終也歸于“develop”分支,實作方式是:

git checkout devleopgit merge –no-ff myfeature(–no-ff,即not fast forward,其作用是:要求git merge即使在fast forward條件下也要産生一個新的merge commit)(此處,要求采用–no-ff的方式進行分支合并,其目的在于,希望保持原有“Feature branches”整個送出鍊的完整性)git branch -d myfeaturegit push origin develop

Git 分支管理是一門藝術

12

“Release branch”,起源于develop分支,最終歸于“develop”或“master”分支。這類分支建議命名為“release-*”

13

“Relase branch”通常負責“短期的釋出前準備工作”、“小bug的修複工作”、“版本号等元資訊的準備工作”。與此同時,“develop”分支又可以承接下一個新功能的開發工作了。

14

“Release branch”産生新送出的最好時機是“develop”分支已經基本到達預期的狀态,至少希望新功能已經完全從“Feature branches”合并到“develop”分支了。

15

建立“Release branches”,方法是:

git checkout -b release-1.2 develop./bump-version.sh 1.2 (這個腳本用于将代碼所有涉及版本資訊的地方都統一修改到1.2,另外,需要使用者根據自己的項目去編寫适合的bump-version.sh)git commit -a -m “Bumped version number to 1.2″

16

在一段短時間内,在“Release branches”上,我們可以繼續修複bug。在此階段,嚴禁新功能的并入,新功能應該是被合并到“develop”分支的。

17

經過若幹bug修複後,“Release branches”上的代碼已經達到可釋出狀态,此時,需要完成三個動作:第一是将“Release branches”合并到“master”分支,第二是一定要為master上的這個新送出打TAG(記錄裡程碑),第三是要将“Release branches”合并回“develop”分支。

git checkout mastergit merge –no-ff release-1.2git tag -a 1.2 (使用-u/-s/-a參數會建立tag對象,而非軟tag)git checkout developgit merge –no-ff release-1.2git branch -d release-1.2
           

18

“Hotfix branches”源于“master”,歸于“develop”或“master”,通常命名為“hotfix-*”

19

“Hotfix branches”類似于“Release branch”,但産生此分支總是非預期的關鍵BUG。

20

建議設立“Hotfix branches”的原因是:希望避免“develop分支”新功能的開發必須為BUG修複讓路的情況。

Git 分支管理是一門藝術

21

建立“Hotfix branches”,方法是:

git checkout -b hotfix-1.2.1 master./bump-version.sh 1.2.1git commit -a -m “Bumpt version to 1.2.1″ (然後可以開始問題修複工作)git commit -m “Fixed severe production problem” (在問題修複後,進行第二次送出)
           

22

BUG修複後,需要将“Hotfix branches”合并回“master”分支,同時也需要合并回“develop”分支,方法是:

git checkout mastergit merge –no-ff hotfix-1.2.1git tag -a 1.2.1git checkout developgit merge –no-ff hotfix-1.2.1git branch -d hotfix-1.2.1
           

23

還記得文章開始時的那張大圖麼,我建議你把這幅大圖從這裡下載下傳下來,列印出來,貼在你寫字台的牆壁上,好處不言而喻。

over~

轉載于:https://www.cnblogs.com/andy-zhou/p/5323691.html

git