模板
教程
环境
性能
功能
管理
介绍一个成功的 Git 分支模型(3)
创建新分支以后，切换到该分支，添加版本号。这里，bump-version.sh 是一个虚构的shell脚本，它可以复制一些文件来反映新的版本(这当然可以手动改变–目的就是修改一些文件)。然后版本号被提交。
这个新分支可能会存在一段时间，直到该发行版到达它的预定目标。在此期间，bug的修复可能被提交到该分支上(而不是提交到develop分支上)。在这里严格禁止增加大的新features。他们必须合并到develop分支上，然后等待下一次大的发行版。
完成一个release分支
当一个release分支准备好成为一个真正的发行版的时候，有一些工作必须完成。首先，release分支要合并到master上(因为每一次提交到master上的都是一个新定义的发行版，记住)。然后，提交到master上必须打一个标签，以便以后更加方便的引用这个历史版本。最后，在release分支上的修改必须合并到develop分支上，以便未来发行版也包含这些bugs的修复。
在Git中的前两步是：
|
1
2
3
4
5
6
|
$ git checkout master Switched to branch 'master'$ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) $ git tag -a 1.2 |
发行版现在已经完成，为以后引用打上标签。
编辑：你可能也想使用the-sor-u flags来标记你的标签。
为了是修改保持在release分支上，我们需要合并这些到develop分支上去，在Git上：
|
1
2
3
4
5
|
$ git checkout develop Switched to branch 'develop'$ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) |
这个步骤可能会导致合并冲突(可能由于改变版本号更是如此)。如果是这样，修复它然后提交。
现在我们真正的完成了，这个release分支将被删除，因为我们不再需要它了。
|
1
2
|
$ git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe). |
热修复分支
可以基于master分支，必须合并回develop和master分支。
分支名约定：hotfix-*
热修复分支与发布分支很相似，他们都为新的生成环境发布做准备，尽管这是未经计划的。他们来自生产环境的处于异常状态压力。当生成环境验证缺陷必须马上修复是，热修复分支可以基于master分支上对应与线上版本的tag创建。
其本质是团队成员(在develop分支上)的工作可以继续，而另一个人准备生产环境的快速修复。
创建修补bug分支
hotfix branch(修补bug分支)是从Master分支上面分出来的。例如，1.2版本是当前生产环境的版本并且有bug。但是开发分支(develop)变化还不稳定。我们需要分出来一个修补bug分支(hotfix branch)来解决这种情况。
原文转自：http://blog.jobbole.com/34706/
