工作流简介
功能驱动开发
"功能驱动式开发"（Feature-driven development，简称FDD）.
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
如果我们开发的内容在功能的角度上就存在不相容，无法合并，则这种工作流未必合适。从项目设计上讲应该尽量避免这种情况的出现，否则，建议分割项目来解决。
Git flow(Git 工作流)
Git工作流比喻项目像流水一样顺畅自然的向前流动,不会发生冲击，对撞，甚至漩涡。
目前用的比较广泛的工作流有三种:
- Git flow
- Github flow
- Gitlab flow
针对目前的项目状况，本文采用的是最早诞生，并得到广泛应用的Git flow和功能驱动开发（FDD）以及带问题追踪的功能分支管理的GitLab flow结合。
Git flow
首先，项目存在两个长期分支。
主分支master
开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在三种短期分支。
功能分支（feature branch）
补丁分支（hotfix branch）
预发布分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。
GIT Flow总览
主分支Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
对应到目前团队中使用的Gitlab,我们建议使用Master作为主分支并设置分支保护（默认设置）,每次发布打上Tag,如: 0.1, 0.2或0.3
开发分支Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
由于Gitlab中默认对Master设置了分支保护(这个设置允许取消,如果存在多人开发的项目,不建议取消),所以,当需要合并到Master的时候需要在Gitlab里提交合并申请,由项目管理员合并.
功能分支Feature
功能分支属于临时性分支,一般合并完就会删除.
它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
某些情况下,新功能可能需要在线上的版本保持一致,可以从Master里拉出功能分支,也可以.
实际应用功能分支的时候,存在以下几种情况:
1、正常迭代,周期性的功能需求
2、公共模块更新，所有feature分支都需要同步更新
3、产品型需求,这种需求的周期很长，需求和项目的主线有很大偏差，同时要求不跟着主板本迭代
第一种情况，按照标准的feature分支工作流开展即可,不再赘述。
第二种情况，需要分别关注两种情况的处理。
1、作为公共模块更新提交者，在本地分支commit后，不在develop分支需要切换到develop分支并pull request，然后修改公共模块，最后提交到remote（单次commit的代码只能包含修改公共模块的代码，不能包含UI、其他feature分支代码）。
2、作为公共模块拉取者，在本地分支commit后，fetch更新remote提交记录，然后cherry-pick对应的commit记录。
产品型需求
这种分支建议以production-分支定义,在功能迭代完成后直接在production-分支上拉出release分支提测,测试完成后,合并回production分支,同时在production分支上打上tag.
由于这种分支并不合并到主干,所以上线的代码都体现在production分支上,如果线上有bug需要修复,在tag上拉出fixbug分支修复即可.
这种分支实际上相当于一个独立的项目进行迭代,和本文阐述的分支管理主旨并不相符.
预发布分支
它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支,合并完后删除分支。
它的命名，可以采用release-*的形式。
hotfix分支
软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修复。
hotfix分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用hotfix-*的形式。
hotfix分支在提交的时候,如果存在release分支,需要同时合并到release分支,避免release分支上线的时候,合并到master有冲突.
分支命名规范
| 分支类型 | 命名 | 说明 |
|---|---|---|
| 主干 | master | |
| 开发分支 | develop | |
| 功能分支 | feature_* | 使用禅道的需求编号或者需求的拼音缩写（Tower任务没有编号） |
| 预发布分支 | release_* | 使用版本号，如: 1.1.2 |
| hotfix分支 | hotfix_* | 根据当前tag版本号增加，如：1.1.2.1 |
| 产品分支 | production_* | 产品分支，对于独立进化的分支管理 |
受保护的分支
默认情况下，受保护的分支执行以下四个简单的操作：
- 它会阻止除具有“主”权限的用户之外的所有用户创建（如果尚未创建）
- 它可以防止除具有“主”权限的用户以外的其他任何人推送
- 它可以防止任何人强制推送分支
- 它阻止任何人删除分支
版本迭代管理
为了适应高速迭代开发节奏，我们会以一个月两个版本迭代开发，每个版本需要安排主程序员和开发人员，在单次版本开发中，主程序员的职责是统筹开发人员，负责主要开发任务，收集bug并反馈到开发人员手里，以及feature分支合并申请审核。而开发人员只需要完成开发任务和bug修复。下一个版本主程序员和开发人员轮换。
扩展讨论
如何将现有的工作流切换过来？
若手头还有工作，需要在你当前分支处理的话，可以按照以前的工作流提交你的代码，并且提交完代码后，需要每一位开发者同步一下代码，之后按照功能驱动式开发即可。
参考文档
Git工作流程
A successful Git branching model
Understanding the GitHub flow
GitHub Flow