一个成功的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/