是一套基于git的工作流程，这个工作流程围绕着project的发布(release)定义了一个严格的如何建立分支的模型。
简而言之就是每一个特性(feature)的开发并不直接在主干上开发，而是在分支上开发，分支开发完毕后再合并到主干上。
这样做的好处是：
- 还处于半成品状态的feature不会影响到主干
- 各个开发人员之间做自己的分支，互不干扰
- 主干永远处于可编译、可运行的状态
master分支只存放历史发布(release)版本的源代码。各个版本通过tag来标记。上图里的v0.1和v0.2就是tag。
develop分支则用来整合各个feature分支。开发中的版本的源代码存放在这里。
每一个特性(feature)都必须在自己的分支里开发，feature分支派生自develop分支。
当feature开发完毕后，要合并回develop分支。feature分支永远不会和master分支打交道。
-
[任务编号] - [概述]。如：
DS188-preprocess-data，其中DS188为任务编号 -
[姓名] - [概述]。如：
guang-preprocess-data
release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。
我们用这个分支干所有和发布有关的事情，比如：
- 把这个分支打包给测试人员测试
- 在这个分支里修复bug
- 编写发布文档
所以在这个分支里面绝对不会添加新的特性。
当和发布相关的工作都完成后，release分支合并回develop和master分支。
单独搞一个release分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。
一个项目发布后或多或少肯定会有一些bug存在，而bug的修复工作并不适合在develop上做，这是因为
- develop分支上包含还未验证过的feature
- 用户未必需要develop上的feature
- develop还不能马上发布，而客户急需这个bug的修复。
这时就需要新建hotfix分支，hotfix分支派生自master分支，仅仅用于修复bug，当bug修复完毕后，马上回归到master分支，然后发布一个新版本，比如v0.1.1。
同时hotfix也要合并回develop分支，这样develop分支就能享受到bug修复的好处了。
- develop，release和master分支均由小组组长管理，组员无write权限
- 当组员在各自feature分支上开发完成，须发送pull request至develop分支
- 组长收到pull request之后，审核并同意pull request; 或召集组员发起code review后通过pull request
- 如果pull request未通过，组长须在pull request中指出原因，组员修改后即可通知组长进行二次审核