一、分支分类
Git Flow 是最早出现也是最经典的一种分支管理策略，它由两个长期分支和三种类型的临时分支组成。
1、永久分支：
Master 分支
主分支。用于存放经过测试，完全稳定的代码。永远都是可发布分支。
Develop 分支
开发分支一开始从master分离而来，用于存放基本稳定的代码。当该分支代码稳定，可发布版本时，合并到master分支上。
2、临时分支
Feature 分支
功能模块分支，从dev分支分离而来，用于开发项目功能，当开发新功能时以
feature -xxx
命名，开发完成后，合并到develop上，合并后删除自己。
Release 分支
版本预发布分支，当v1.0.1版本发布时，可以从develop分支签出release-1.0.1，进行测试，测试出现问题，在release-1.0.1进行修改，测试完毕后准备发布将代码合并至master分支和develop分支上，给master打上v1.0.1的标签，合并后删除自己，这样做可以不影响下个版本功能的开发。
Hotfix 分支
线上紧急bug修复的分支，命名为hotfix-xxx,修改完成后，合并到master分支和develop分支，合并到master后打上修复版本的tag,合并后删除自己。
二、工作流程
我们以流程图的形式展开了解
详细说明：
我们程序刚创建的时候只有默认的
master
分支，也就是节点
A
，这时我们需要进行功能版本的开发，于是从
A
节点签出一个
develop
分支，这时就有了节点
B
，于是当我们要进行新功能的开发时候，从
B、C
时间点签出到
feature
分支的
D、E
进行功能的开发，当功能开发完成后相继有了
F、G
，然后我们将完成的新功能合并到
develop
分支上
I
点、然后进行测试，测试中发现有Bug,进行修复，进而有了
J、K
节点然后当测试完成稳定后，将预发布分支
release
合到
develop
分支和
master
分支，得到了节点
L、M
，
master
上每次合并的时候都需要打上tag,
M
节点需要打上相应的tag,标记一个发布版本，然后项目上线，上线后出现紧急Bug,需要签出到
hotfix
分支，进行修复，修复后将代码合并到
develop
和
master
分支。
其中
feature、release、hotfix
完成合并到
develop
和
master
后需要删除对应的分支。
根据工作中公司要求不同，有的公司可能会省略develop分支，有的会有testing分支专门用来测试使用等等。但是大概需要遵循的规则都是差不多哒。