实际工作中一个好的工作流的重点就是制定一个好的分支管理策略，通常我们使用的工作流大多基于 Gitflow工作流，或者完全遵循或者稍作改变，在这些工作流可能各式各样，但是他们对于分支的管理基本上都是一致的
这里先介绍其中通用的分支管理策略，整个工作流涉及的东西还比较多，后面再介绍，可以先来看 Gitflow工作流 的全貌：
Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织为了解决特定的问题而进行的各种开发活动。
主分支
主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和develop分支
master
master分支应该是最稳定的，也就是最新稳定版本，是要部署生产的，要保持master分支的干净。
当开发到一定阶段，需要发布生产，master会被更新，每一次更新，都要打上新的版本号的tag。
develop
develop 被用来做后续开发或者测试稳定性，不是绝对稳定的分支，当达到了一定的稳定状态（完成功能，测试通过），就可以将其合并到master分支
辅助分支
feature
从develop分支上派生，用来开发新的功能，开发完成后合并回develop分支。
一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
release
- 从develop分支上派生
- 最终合并回develop分支和master分支
- 命名习惯：
release-*
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
hotfix
从master分支派生
最终合并到master分支和develop分支
命名习惯 ：
hotfix-*
当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。