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

　　$ git commit -a -m “Bumped version number to 1.2.1″

　　[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1

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

　　不要忘了在創建熱補丁分之后設定一個新的版本號!

　　然后，修復bug并使用一個或者多個單獨的commit提交。

　　$ git commit -m “Fixed severe production problem”

　　[hotfix-1.2.1 abbe5d6] Fixed severe production problem

　　5 files changed, 32 insertions(+), 17 deletions(-)

　　結束一個熱補丁分支

　　修復完成后，熱補丁分支需要合并回master，但同時它還需要被合并回develop，這樣相關的修復代碼才會同時被包含在下個版本中。這與我們完成發布分支很類似。

　　首先，更新master分支并打上標簽。

　　$ git checkout master

　　Switched to branch ‘master’

　　$ git merge –no-ff hotfix-1.2.1

　　Merge made by recursive.

　　(Summary of changes)

　　$ git tag -a 1.2.1

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

　　接著，將修復代碼合并到develop：

　　$ git checkout develop

　　Switched to branch ‘develop’

　　$ git merge –no-ff hotfix-1.2.1

　　Merge made by recursive.

　　(Summary of changes)

　　這里還有個例外情況，如果這個時候有發布分支存在，熱補丁分支的變更則應該合并至發布分支，而不是develop。將熱補丁合并到發布分支，也意味著當發布分支結束的時候，變更最終會被合并到develop。(如果develop上的開發工作急需熱補丁并無法等待發布分支完成，這時你也已經可以安全地將熱補丁合并到develop分支。)

　　最后，刪除臨時的熱補丁分支：

　　$ git branch -d hotfix-1.2.1

　　Deleted branch hotfix-1.2.1 (was abbe5d6).

　　小結

　　雖然這個分支模型中沒有什么特別新鮮的東西，但本文起始處的“全景圖”事實上在我們的項目中起到了非常大的作用。它幫助建立了優雅的，易理解的概念模型，使得團隊成員能夠快速建立并理解一個公用的分支和發布過程。

　　我同時也提供了一個該圖對應的高質量PDF版本。你可以打印出來并掛在墻上，隨時參考。

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