文章目录
- [一、git flow](#一、git flow)
- [二、github flow](#二、github flow)
- [三、gitlab flow](#三、gitlab flow)
- [四、基于gitlab flow的最佳实践](#四、基于gitlab flow的最佳实践)
- 参考
业界包含三种flow：
- Git flow
- Github flow
- Gitlab flow
三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。
- 它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
一、git flow
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
首先，项目存在两个长期分支。
- 主分支master
- 开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在三种短期分支。
- 功能分支（feature branch）
- 补丁分支（hotfix branch）
- 预发分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。
缺点：
- 单独使用 git flow 命令管理
bash
sudo apt-get install git-flow -y- 综合考虑了开发、测试、新功能开发、临时需求、热修复，理想很丰满，现实很骨干，这一套运行起来实在是太复杂了。
二、github flow
它只有一个长期分支，就是master，因此用起来非常简单。
官方推荐的流程如下：
第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
缺点：
- github flow这种方式，要保证高质量，对于贡献者的素质要求很高，换句话说，如果代码贡献者素质不那么高，质量就无法得到保证。
三、gitlab flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
（1）上游优先
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
Chromium项目就是一个例子，它明确规定，上游分支依次为：
- Linus Torvalds的分支
- 子系统（比如netdev）的分支
- 设备厂商（比如三星）的分支
（2）持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。
对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。
开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
（3）版本发布
对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
缺点：
- gitlab flow 如何处理hotfix？ git flow之所以这么复杂，一大半原因就是把hotfix考虑得太周全了。hotfix的意思是，当代码部署到产品环境之后发现的问题，需要火速fix。gitlab flow 可以基于后续分支，修改后上线。
四、基于gitlab flow的最佳实践
采用gitlab flow，按照版本发布的模式实施，具体来说：
- 新的迭代开始，所有开发人员从主干master拉个人分支开发特性, 分支命名规范 feature-name
- 开发完成后，在迭代结束前，合入master分支 master分支合并后，自动cicd到dev环境
- 开发自测通过后，从master拉取要发布的分支，release-$version，将这个分支部署到测试环境进行测试
- 测出的bug，通过从release-versio拉出分支进行修复，修复完成后，再合入release-version
- 正式发布版本，如果上线后，又有bug，根据5的方式处理 等发布版本稳定后，将release-$versio反合入主干
1.语义化版本号
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译元数据可以加到"主版本号.次版本号.修订号"的后面，作为延伸。
主版本号为0，代表还未发布正式版本。
2.测试发布
master分支，自动部署到开发环境（dev）
功能开发完成，并自测通过后，代码合并到待发布版本，
分支规则：
bash
release-$version版本规则:
bash
主版本号.次版本号.修订号从最新的master新拉一个分支release-$version，比如release-0.1.1
bash
git checkout -b release-0.1设定release-$version 分支为保护分支，不允许直接推送，只能通过merge不允许直接提交代码，接受MR。
3.bug修复
需要修改bug时，从release-version新拉分支，修改完成后再合并到release-version分支.
Q: 从release-$version拉的分支，如何测试？
A: 这个节点定义为bug修复节点，建议开发同学优先本地测试验证，严重通过再合并到release分支。
Q: release-$version太多怎么办？
A: 可以保留最近的10个版本。历史的打tag后，删除分支。