gitflow工作流是一种依赖于Git版本管理工具，按特定规范对项目开发、测试、上线流程进行管理的工作方式。它是一种为实现规范化管理的约定，它明确了各个分支的意义，使整个团队的分工协作更加和谐明晰。
一、gitflow工作流约定使用的分支简介
【master】项目的核心分支，也是最终对外发布的分支，唯一且稳定。仅提供可读，不可在该分支上直接修改代码。
【develop】项目的开发主干分支，唯一。仅提供可读，不可在该分支上直接修改代码。新功能的开发需从该分支拉取新的分支展开。develop分支应该包含项目完整的全部历史记录。
【featrue】项目的需求开发分支，可多个，从develop分支或其他featrue分支拉取。程序员的多人分工协作即通过featrue来实现，是代码具体实现的一线程序员接触最多的分支。需求开发完成后，要合并回develop分支。
【release】预发布分支，通常被叫做测试分支，主要用于开发阶段的测试及bug修复。当feature分支开发完毕后会合并回develop分支，然后再从develop分支拉取release分支提测。测试并修复后的release分支要合并回develop分支以及master分支，并打上合适的tag标记(包含必要的releaseNote)。
【hotfix】紧急线上修复分支，即当对外发布的master分支出现重大bug，影响线上使用时，从master分支拉取hotfix分支进行紧急修复。修复后的hotfix分支要合并回master分支和develop分支。
二、gitflow工作流流程图
下面，以新项目开发或旧项目转gitflow模式的场景来介绍gitflow工作流的运作。
首先，完成中央仓库的初始化，将新项目搭建起框架后的工程代码或要转gitflow的项目代码上传至git中央仓库。项目负责人克隆中央仓库到本地形成master分支，并拉取develop分支(步骤①)推送至服务器。一般的实际场景，开发团队中只有项目负责人有权限操作master分支，拉取develop分支，并将develop分支的代码合并到master分支中。
然后，开发团队中的其他人克隆中央仓库的develop分支到本地，形成全体成员统一的唯一的develop分支轨迹。之后，按照需求及成员各自的分工，各个成员可以从develop分支拉取出各自的featrue分支(步骤②)进行独立的开发；若涉及到多人合作开发同一分支，拉取的分支要及时推送至服务器，便于各成员共享。
当各成员完成各自的功能开发后，需将完成后的代码提交到featrue分支，然后合并到develop分支(步骤③)。代码合并后，featrue分支可以不再保留。
功能累积足够且稳定或到达约定的提测周期时，项目负责人应当从develop分支拉取出release分支(步骤④)，打包提交相应的版本给测试人员进行部署测试，测试中提交的bug全部在该release分支完成修改。
测试结束并完成bug修复后，release分支应该合并回develop分支和master分支(步骤⑤)，代码合并后，release分支可以不再保留。合并后的master分支，应由项目负责人及时推送到中央仓库(步骤⑥)。同时全体成员要及时同步自己develop分支。
有上线需求时，直接从master分支打包提交应用版本进行部署。当线上版本出现重大bug，项目负责人需从master分支拉取hotfix分支(步骤⑦)，进行线上的紧急修复。
最后，修复后的hotfix分支要合并回develop分支和master分支(步骤⑧)。并推送到中央仓库(步骤⑨)。
三、开发分支内部开发者们的合作模式
在gitflow工作流中，此处的公共服务器可以理解为develop分支，主开发者掌握featrue分支的读写权限，其他开发者拉取副本后，各自独立开发，完成后将更新的patch提交给主开发者。最终由主开发者统一完成featrue分支的提交与合并。
参考文献：（文章仅做交流学习，侵权即删！！）
1、https://www.jianshu.com/p/cb96825ff89e
2、https://segmentfault.com/a/1190000002918123?utm_source=tag-newest