上一篇文章中我们提到了在一个周维度或者月维度发布产品的小型协作项目中，会遇到各类协作上的问题，随着发布的越来越紧凑，问题也就越来越突出。本文主要对上一篇文章中提到的问题解决方案做细化，让大家可以清楚的知道如何通过合理的 git 工作流来解决这些问题，让原来发布时的手忙脚乱不再出现。通过 git flow 我们可以对项目做一个分支模型管理：
- master 固定，一致保持当前最新稳定的发布版本代码，在 CI/CD 建设时，你可以只在该分支做签名、公证等一系列自动化流程
- develop 固定，这是我们日常的开发分支，所有新功能分支都将合并到该分支
- release/* 可删，进入预发布阶段时基于 develop 创建的分支，再此基础集成，它名字可能是 release/2.8.0，release/2.9.0 等。
- bugfix/* 可删，这种分支一般情况下基于 develop 或者 release/* 分支开出，作为简单的缺陷修复分支，最终合并到 develop 或 release/* 分支中
- hotfix/* 可删，是对线上最新版本或长期服务版本做紧急修复时使用的分支，他不是常驻的
说多不多，说少也不少，还没有了解 git-flow 的同学可能会有点不太好理解，下面就详细介绍每个分支类型是如何在我们平时工作协作中起到重要作用的。