在正式开始开发项目前，我们团队各个小伙伴就项目中需要考虑的问题分头进行了资料搜集，并一起开会讨论了我们项目的架构、技术选型等问题。其中一个问题是在多人协作开发时，如何高效地使用版本管理工具，也即选择合适的工作流。
经过讨论，我们团队选择了gitflow作为我们的工作流方案。
本文将简单地介绍gitflow工作流方案。而由于作者也是刚接触gitflow，有错误之处还望大佬们指正。
01 优势与劣势
优势
- 在项目周期之内，该工作流保证任何时刻两个主要分支都是处于纯净状态的
- 由于遵循系统化的模式，因此分支命名容易理解
- 大多数Git工具都支持该工作流的扩展工具
- 当项目中需要同时维护多个生产版本时，该工作流模式非常理想
缺陷
- Git 的历史记录将变得异常混乱，可读性很差
- master / develop 分支的割裂使CI/CD流程变得更加困难
- 当项目维护单一生产环境版本时，该工作流则不适用
02 常用分支
gitflow 的主要有以下五个分支:
- master
Master分支是仓库的主分支，这个分支包含最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改。 - hotfix
分支基于master分支创建，对线上版本的bug进行修复，完成后直接合并到master分支和develop分支，如果当前还有新功能release分支，也同步到release分支上。同一时间只有1个，生命周期较短。 - release
当你需要发布一个新功能的时候，要基于Develop分支创建一个Release分支，在Release分支测试并修复bug，完成release后，把release合并到master和develop分支。 - dev
这个分支是我们的主开发分支，包含所有要发布到下一个Release的代码。 - feature
feature分支主要是用来开发新的功能，一旦开发完成，就合并回Dev分支。同时可以有多个feature分支。
