GitFlow是什么？
GitFlow工作流程围绕项目发布定义了严格的分支模型。尽管它比Feature Branch Workflow更复杂一些，但它也为管理更大规模的项目提供了坚实的框架。
与Feature Branch Workflow相比，GitFlow流程并没有增加任何新的概念或命令。其特色在于，它为不同的分支分配了非常明确的角色，并且定义了使用场景和用法。除了用于功能开发的分支，它还使用独立的分支进行发布前的准备、记录以及后期维护。
流程仍然使用一个中央代码仓库，它是所有开发者的信息交流中心。跟其他的工作流程一样，开发者在本地完成开发，然后再将分支代码推送到中央仓库。唯一不同的是项目中分支的结构。
GitFlow常用分支
master
1.主分支 , 产品的功能全部实现后 , 最终在master分支对外发布。
2.该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改。
3.另外所有在master分支的推送应该打标签做记录，方便追溯。例如release合并到master , 或hotfix合并到master。
develop
1.主开发分支 , 基于master分支克隆。
2.包含所有要发布到下一个release的代码。
3.该分支为只读唯一分支 , 只能从其他分支合并。
4.feature功能分支完成 , 合并到develop(不推送)。
5.develop拉取release分支 , 提测。
6.release/hotfix 分支上线完毕 , 合并到develop并推送。
feature
1.功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发。
2.功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库)。
3.feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除。
release
1.测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆。
2.主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag。
3.属于临时分支 , 功能上线后可选删除。
hotfix
1.补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复。
2.修复完毕后合并到develop/master分支并推送 , 打Tag。
3.属于临时分支 , 补丁修复上线后可选删除。
4.所有hotfix分支的修改会进入到下一个release。
GitFlow工作流程图
