概览
一个项目涉及到多个模块多个团队进行开发时，则需要将git分支进行规范化管理
这种模式下，主要维护两类分支：
- 主要分支
- master
- develop
- 辅助分支
- featrue branch（功能分支）
- hotfixes branch（热修复分支）
master
代码库中有且只有一个主分支，master 分支的代码是最稳定的，可以随时发布到生产环境。
develop
用于日常开发，保存开发过程中最新的代码。
当 develop 分支上的代码达到稳定时，并具备发版状态时，将 develop 的代码合并到 master，并且打一个带有发布版本号的 tag。
feature
从 develop 分支上拉取一个新的分支，开发某个新的功能，开发完成之后，在合并到 develop 分支，功能分支通常只存在于开发者的本地仓库，并不包含在远程库中。
hotfix
从 master 分支上拉取，为修复分支。软件正式发布之后难免会出现bug，会在hotfix上进行代码修复。修复结束之后合并到 master 和 develop 分支上。
总结
优点：
- 各个分支职责分明，是很多分支管理策略的启蒙模型
缺点：
- 合并冲突：多个分支可能会很多，有一些并行的feature 分支，很有可能发生冲突。频繁手动解决冲突不仅增加了工作量，而且增大了出错的风险。
- 功能分离：并行开发时，合并分支前无法测试组合功能，而且合并之后可能会有影响。
- 无法持续交付：一个 feature 分支要经历很多步骤才能发不到正式环境，难以达到交付的要求。
- 无法持续集成：持续集成鼓励更加频繁的代码集成和交互，尽早解决冲突。而 Git Flow 的分支策略隔离了代码，尽可能推迟代码集成。