其本质是团队成员(在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格式图表。去吧，把它挂载墙上以便能随时快速参考。