由于最近在开发的项目是需要和一些国外的开发共同完成， 因此我们使用的工作流方式被提出了质疑。于是仔细查了一下，大家共勉。
git flow
这是我们之前一直在用的一种模式，用了接近4年，从我们项目的network也可以看出这种模式最大的优点，清晰。
只不过从github的更新时间可以看出，代码已经7年没有更新过了，即使还有很多的issue和PR。
A successful Git branching model
特点：
- 两个长期分支：master和develop
- 三个短期分支：feature(功能)、hotfix(补丁)、release(预发)
优点：
- 各个feature之间代码隔离，可以独立开发、测试，分支清晰
- 当feature开发周期长于release周期，可以避免未完成的feature进入生产环境
缺点：
- 分支开发时间较长时，开发成本较高。可能新创建的分支会基于错的代码进行开发
- 当部署较频繁时，没必要同时维护两个分支
- 分支较多时，合并代码时容易存在冲突
- 规则较多，学习成本相对来说会高一些
应用场景：
- 需要支持多个版本的软件并且相互独立
- 多版本独立，同时后续各版本开发
github flow
相对于git flow来说，github flow更简单，缩短了开销。
特点：
- 只有一个master分支为长期分支
anything in the master branch is always deployable.只要在master分支中的代码一定是可以部署的- 新建的分支名称需体现此分支的作用
优点：
- 规则简单
缺点：
- master合并后如果不发布，会造成线上和master不一致
应用场景：
- 需要频繁部署，且立即部署的项目
- 适合小型项目，开发人员少的项目
gitlab flow
- master为主分支
- 拥有环境分支pre-production(预发分支)、production(生产分支)
优点：
- 清晰可控
- 规则相对git flow来说更简单
缺点：
- 相对于github flow来说，gitlab flow 更复杂
- 当维护较多版本时，会变得像git flow似的比较复杂
应用场景：
- 需要进行预发布的项目
- github推荐的工作流方式
总结
这三种是市场上使用的比较多的方式，各自都有各自的优缺点，大家还是应该根据实际项目来选择不同的方式对git进行管理，毕竟每一个同学都不想看见乱糟糟的network
