其本質是團隊成員(在develop分支上)的工作可以繼續，而另一個人準備生產環境的快速修復。
創建修補bug分支
hotfix branch(修補bug分支)是從Master分支上面分出來的。例如，1.2版本是當前生產環境的版本并且有bug。但是開發分支(develop)變化還不穩定。我們需要分出來一個修補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(-)
分支關閉的時侯不要忘了更新版本號(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也包含到下一個發行版中。這一點和完成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 參數來對你的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)
規則的一個例外是： 如果一個release分支已經存在，那么應該把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).
摘要
盡管這個分支模型沒有任何震撼的新東西， 文章開頭的圖表在我們的項目中表現出驚人的實用性。它形成了一個優雅的思維模型，易于領悟并使團隊成員發展出對分支和發布過程的共同理解。
這里提供一份高質量PDF格式圖表。去吧，把它掛載墻上以便能隨時快速參考。
