Git作为分布式版本控制系统，不可避免涉及到团队协作。
对于多人协作开发的项目，需要规范且有效的协同开发，才能让系统有序地开发并维护下去。
工作流即“workflow"或者"flow"，意为像流水一样延续的状态。
Git flow是什么？
2010年5月，原Git Prime的首席技术官Vincent Driessen在一篇名为“A successful Git branching model”的博文中介绍了一种构建在Git（一个开源的分布式版本控制系统）之上的软件开发模型。通过利用Git创建和管理分支的能力，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上，实现了软件开发过程不同阶段的相互隔离。这种软件开发的活动模型被Vincent称为“Git Flow”（Git工作流程）。Git Flow已经开始流行于基于主干的工作流，它现在被认为是现代连续软件开发和DevOps（开发、技术运营和质量保障三者的交集）实践的最佳实践。
Vincent博文中的Git Flow流程图
Git flow分支说明
Git flow的核心是branches（分支），通过在项目的不同阶段，对分支进行不同的操作（创建、合并等）完成一个有序且连贯的项目。
master
主分支：发布稳定的版本，每一次发布需要打上相应的版号。
hotfix
热修补分支：对主分支上的版本进行不下线紧急修补。好处是修补不会影响开发分支的正常工作。
release branch
预发布分支：feature分支合并到develop之后 , 从develop分支克隆。主要用于给测试人员进行功能测试，bug修复后合并到develope或者master。
develope
开发分支：其上的代码反映着下一个版本需要的功能。支持辅助分支的合并操作，最常见的是合并功能分支。
feature branches
功能分支：基于develope分支克隆，主要作用是开发各种功能。一般存在于开发人员的本地代码库而不需要提交至远程代码库。
主要工作流程
1 . 初始化项目 , 默认创建master分支 , 然后从master拉取develop分支
2 . 从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)
3 . feature分支完成后 , 合并到develop
4 . 从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG
5 . release分支上线后 , 合并release分支到develop/master并推送
6 . 上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改
7 . hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送
注：
当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上
当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上
Git Flow模型通过不同的分支从源代码管理的角度对软件开发活动进行了约束，为软件开发提供了一个可供参考的管理模型。Git Flow模型让代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。
