一個成功的Git分支模型(2)

　　在第2張圖中，已經無法一眼從Git歷史中看到哪些commit對象構成了一個特性——你需要閱讀日志以獲得該信息。在這種情況下，回退(revert)整個特性(一組commit)就會比較麻煩，而如果使用了–no-diff就會簡單很多。

　　是的，這么做會造成一些(空的)commit對象，但這么做是利大于弊的。

　　可惜的是，我沒能找到方法讓–no-diff成為默認的git merge行為參數，但其實應該這么做。

　　發布分支

　　可能的分支來源：develop

　　必須合并回：develop和master

　　分支命名約定：release-*

　　發布分支為準備新的產品版本發布做支持。它允許你在最后時刻檢查所有的細節。此外，它還允許你修復小bug以及準備版本發布的元數據(例如版本號，構建日期等等)。在發布分支做這些事情之后，develop分支就會顯得比較干凈，也方便為下一大版本發布接受特性。

　　從develop分支創建發布分支的時間通常是develop分支(差不多)能反映新版本所期望狀態的時候。至少說，這是時候版本發布所計劃的特性都已經合并回了develop分支。而未來其它版本發布計劃的特性則不應該合并，它們必須等到當前的版本分支創建好之后才能合并。

　　正是在發布分支創建的時候，對應的版本發布才獲得一個版本號——不能更早。在該時刻之前，develop分支反映的是“下一版本”的相關變更，但不知道這“下一版本”到底會成為0.3還是1.0，直到發布分支被創建。版本號是在發布分支創建時，基于項目版本號規則確定的。

　　創建一個發布分支

　　發布分支從develop分支創建。例如，假設1.1.5是當前的產品版本，同時我們即將發布下個版本。develop分支的狀態已經是準備好“下一版本”發布了，我們也決定下個版本是1.2(而不是1.1.6或者2.0)。因此我們創建發布分支，并且為其賦予一個能體現新版本號的名稱：

　　$ git checkout -b releases-1.2 develop

　　Switched to a new branch “release-1.2”

　　$ ./bump-version.sh 1.2

　　Files modified successfully. version bumped to 1.2.

　　$ git commit -a -m “Bumped version number to 1.2”

　　[release-1.2 74d9424] Bumped version number to 1.2

　　1 files changed. 1 insertions(+). 1 deletions(-)

　　創建新分支并轉到該分支之后，我們設定版本號。這里的bump-version.sh是一個虛構的shell腳本，它修改一些本地工作區的文件以體現新的版本號。(當然這也可以手動完成——這里只是說要有一些文件變更)接著，提交新版本號。

　　新的發布分支可能存在一段時間，直到該版本明確對外交付。這段時間內，該分支上可能會有一些bug的修復(而不是在develop分支上)。在該分支上添加新特性是嚴格禁止的。新特性必須合并到develop分支，然后等待下一個版本發布。

　　結束一個發布分支

　　當發布分支達到一個可以正式發布的狀態時，我們就需要執行一些操作。首先，將發布分支合并至master(記住，我們之前定義master分支上的每一個commit都對應一個新版本)。接著，master分支上的commit必須被打上標簽(tag)，以方便將來尋找歷史版本。最后，發布分支上的變更需要合并回develop，這樣將來的版本也能包含相關的bug修復。

　　前兩步在Git中的操作：

　　$ git checkout master

　　Switched to branch ‘master’

　　$ git merge –no-ff release-1.2

　　Merge made by recursive.

　　(Summary of changes)

　　$ git tag -a 1.2

　　現在版本發布完成了，而且為未來的查閱提供了標簽。

　　提醒：你可能同時也會想要用 -s 或者 -u 來對標簽進行簽名。

　　為了能保留發布分支上的變更，我們還需要將分支合并回develop。在Git中：

　　$ git checkout develop

　　Switched to branch ‘develop’

　　$ git merge –no-ff release-1.2

　　Merge made by recursive.

　　(Summary of changes)

　　這一操作可能會導致合并沖突(可能性還很大，因為我們改變了版本號)。如果發現，則修復之并提交。

　　現在工作才算真正完成了，最后一步是刪除發布分支，因為我們已不再需要它：

　　$ git branch -d release-1.2

　　Deleted branch release-1.2 (was ff452fe).

　　熱補丁分支

　　必須合并回：develop和master

　　分支命名約定：hotfix-*

　　熱補丁分支和發布分支十分類似，它的目的也是發布一個新的產品版本，盡管是不在計劃中的版本發布。當產品版本發現未預期的問題的時候，就需要理解著手處理，這個時候就要用到熱補丁分支。當產品版本的重大bug需要立即解決的時候，我們從對應版本的標簽創建出一個熱補丁分支。

　　使用熱補丁分支的主要作用是(develop分支上的)團隊成員可以繼續工作，而另外的人可以在熱補丁分支上進行快速的產品bug修復。

　　創建一個熱補丁分支

　　熱補丁分支從master分支創建。例如，假設1.2是當前正在被使用的產品版本，由于一個嚴重的bug，產品引起了很多問題。同時，develop分支還處于不穩定狀態，無法發布新的版本。這時我們可以創建一個熱補丁分支，并在該分支上修復問題：

　　$ git checkout -b hotfix-1.2.1 master

　　Switched to a new branch “hotfix-1.2.1″

　　$ ./bump-version.sh 1.2.1

　　Files modified successfully, version bumped to 1.2.1.

原文轉自：http://www.juvenxu.com/2010/11/28/a-successful-git-branching-model/