标签：
首先贴出模型图
由图看到，模型包含5种分支
主分支包括 master和development
辅助分支包括 feature release 和hotfix
master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。
当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。
同时，每一次更新，最好添加对应的版本号标签（TAG）。
develop分支是保存当前最新开发成果的分支。
通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。
对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
因此，每次将develop分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。
通常而言，“仅在发布新的可供部署的代码时才更新master分支上的代码”是推荐所有人都遵守的行为准则。
基于此，理论上说，每当有代码提交到master分支时，我们可以使用Git Hook触发软件自动测试以及生产环境代码的自动更新工作。这些自动化操作将有利于减少新代码发布之后的一些事务性工作。
用于开发新功能时所使用。
可以从develop分支发起feature分支。
代码必须合并回develop分支。
feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名称。
feature分支（有时也可以被叫做“topic分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
用于辅助版本发布。
可以从develop分支派生
必须合并回develop分支和master分支
分支命名惯例：release-*
release分支是为发布新的产品版本而设计的。
在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。
通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。
而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。
成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。
所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
用于修正生产代码中的缺陷
可以从master分支派生
必须合并回master分支和develop分支
分支命名惯例：hotfix-*
除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
https://github.com/nvie/gitflow
http://nvie.com/posts/a-successful-git-branching-model/
标签：
原文地址：http://www.cnblogs.com/kakinuma/p/5152217.html
