GIT分支管理是一門藝術 | linux大棚

原創文章屬於《Linux大棚》博客，博客地址為http://roclinux.cn。

文章作者為 rocrocket。

為了防止某些網站的惡性轉載，特在每篇文章前加入此信息，還望讀者體諒。

===

[正文開始]

原文鏈接：http://www.nvie.com/posts/a-successful-git-branching-model/

原文作者：Vincent Driessen

本文經Linux大棚博主總結精簡而成。

1

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

2

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

3

要確保：團隊成員從主分支(master)獲得的都是處於可發布狀態的代碼，而從開發分支(develop)應該總能夠獲得最新開發進展的代碼。

4

在一個團隊開發協作中，我建議，要有「輔助分支」的概念。

5

「輔助分支」，大體包括如下幾類：「管理功能開發」的分支、「幫助構建可發布代碼」的分支、「可以便捷的修複發布版本關鍵BUG」的分支，等等

6

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

7

我建議至少還應設置三類「輔助分支」，我們稱之為「Feature branches」，「Release branches」，「Hotfix branches」。

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

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

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修復讓路的情況。

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~