Git Flow——项目开发中经典分支管理策略

一、分支分类

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分支专门用来测试使用等等。但是大概需要遵循的规则都是差不多哒。