其本質(zhì)是團隊成員(在develop分支上)的工作可以繼續(xù)，而另一個人準備生產(chǎn)環(huán)境的快速修復。

　　創(chuàng)建修補bug分支

　　hotfix branch(修補bug分支)是從Master分支上面分出來的。例如，1.2版本是當前生產(chǎn)環(huán)境的版本并且有bug。但是開發(fā)分支(develop)變化還不穩(wěn)定。我們需要分出來一個修補bug分支(hotfix branch)來解決這種情況。

$ 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.
$ 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(-)

　　分支關(guān)閉的時侯不要忘了更新版本號(bump the version)

　　然后，修復bug，一次提交或者多次分開提交。

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed， 32 insertions(+)， 17 deletions(-)

　　完成一個hotfix分支

　　完成一個bugfix之后，需要把butfix合并到master和develop分支去，這樣可以保證修復的這個bug也包含到下一個發(fā)行版中。這一點和完成release分支很相似。

　　首先，更新master并對release打上tag：
 
$ 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

　　編輯：你可能也會想使用 -sor-u 參數(shù)來對你的tag進行加密

　　下一步，把bugfix添加到develop分支中：

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

　　規(guī)則的一個例外是： 如果一個release分支已經(jīng)存在，那么應(yīng)該把hotfix合并到這個release分支，而不是合并到develop分支。當release分支完成后， 將bugfix分支合并回release分支也會使得bugfix被合并到develop分支。(如果在develop分支的工作急需這個bugfix，等不到release分支的完成，那你也可以把bugfix合并到develop分支)

　　后，刪除臨時分支：

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

　　摘要

　　盡管這個分支模型沒有任何震撼的新東西， 文章開頭的圖表在我們的項目中表現(xiàn)出驚人的實用性。它形成了一個優(yōu)雅的思維模型，易于領(lǐng)悟并使團隊成員發(fā)展出對分支和發(fā)布過程的共同理解。

　　這里提供一份高質(zhì)量PDF格式圖表。去吧，把它掛載墻上以便能隨時快速參考。