简介
Gitflow工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。
Gitflow工作流没有用超出Git的概念和命令，而是为不同的分支分配一个明确的角色，并定义分支之间如何和什么时候进行交互。 除了使用功能分支，在做准备、维护和记录发布时，也定义了各自的分支。
Gitflow工作流定义了一个围绕项目发布的严格分支模型, 提供了一个健壮的用于管理大型项目的框架。
1.工作方式
Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到要中央仓库中。
2.历史分支
相对于使用仅有的一个master分支，Gitflow工作流使用两个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。
3.功能分支
每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。
4.发布分支
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。
常用的分支约定：
用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*
5.维护分支
维护分支或说是热修复（hotfix）分支用于给产品发布版本（production releases）快速生成补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。
6.总结
流程演示
在gitflow工作流中, 开发者和项目经理分别负责不同的工作
开发者
- 创建自己的功能分支
- 在自己的功能分支上进行开发
- 提交合并请求
- 在维护分支和测试分支中对代码进行修改
项目经理
- 创建master/develop分支
- 部署项目到远程仓库
- 设置角色权限
- 审批合并请求
- 合并测试分支到主分支
冲突解决
出现冲突的原因:
- 多人修改了同一个文件同一行
~ 提交合并请求时, 会提示出现冲突
~ 先取消合并请求
git checkout develop
git pull
git checkout f_order
git merge develop
git add
git commit
git push
~ 重新发起合并请求
