高效团队的gitlab flow最佳实践
当前git是大部分开发团队的首选版本管理工具，一个好的流程规范可以让大家有效地合作，像流水线一样有条不紊地进行团队协作。
业界包含三种flow：
- Git flow
- Github flow
- Gitlab flow
下面我们先来分析，然后再基于gitlab flow来设计一个适合我们团队的git规范。
从git flow到gitlab flow
git flow
先说git flow，大概是这样的。
然后，我们老的git规范是参考git flow实现的。
综合考虑了开发、测试、新功能开发、临时需求、热修复，理想很丰满，现实很骨干，这一套运行起来实在是太复杂了。那么如何精简流程呢？
我们来看业界的做法，首先是github flow。
github flow
Github flow 是Git flow的简化版，专门配合”持续发布”。它是 Github.com 使用的工作流程。
整个流程：
- 第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
- 第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
- 第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
- 第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
github flow这种方式，要保证高质量，对于贡献者的素质要求很高，换句话说，如果代码贡献者素质不那么高，质量就无法得到保证。
github flow这一套对于库、框架、工具这样并非最终应用的产品来说，没问题，但是，如果如果一个产品是“最终应用”，github flow可能就不合适了。
gitlab flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
Gitlab flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。
对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
gitlab flow 如何处理hotfix？ git flow之所以这么复杂，一大半原因就是把hotfix考虑得太周全了。hotfix的意思是，当代码部署到产品环境之后发现的问题，需要火速fix。gitlab flow 可以基于后续分支，修改后上线。
团队git规范
综合上面的介绍，我们决定采用gitlab flow，按照版本发布的模式实施，具体来说：
- 新的迭代开始，所有开发人员从主干master拉个人分支开发特性, 分支命名规范 feature-name
- 开发完成后，在迭代结束前，合入master分支
- master分支合并后，自动cicd到dev环境
- 开发自测通过后，从master拉取要发布的分支，release-$version，将这个分支部署到测试环境进行测试
- 测出的bug，通过从release-$versio拉出分支进行修复，修复完成后，再合入release-$versio
- 正式发布版本，如果上线后，又有bug，根据5的方式处理
- 等发布版本稳定后，将release-$versio反合入主干
最佳实践
开发feature功能
新建分支，比如feat-test
开发代码，增加新功能，提交：
@GetMapping(path = "/test", produces = "application/json")
@ResponseBody
public Map<String, Object> test() {
return singletonMap("test", "test");
}
git commit -m "feat: add test code"
git push origin feat-test
提交MR
提交代码后，可以提交mr到master，申请合并代码
Note：
- 这里可以增加自动代码审查,
合并代码
研发组长，打开mr，review代码，可以添加建议：
开发同学根据建议修复代码，或者线下修改后commit代码。
研发组长确认没有问题后，可以合并到master。
合并完成，可以删除feat分支。
新功能开发好，可以进行提测。
发布版本
语义化版本号
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
主版本号为0，代表还未发布正式版本。
测试发布
master分支，自动部署到开发环境（dev）
功能开发完成，并自测通过后，代码合并到待发布版本，
分支规则：
release-version
版本规则
主版本号.次版本号
构建时，自动增加修订号：
主版本号.次版本号.修订号
从最新的master新拉一个分支release-$version，比如release-0.1
git checkout -b release-0.1
release-$version会自动构建，版本号为$version.$buildNumber
设定release-$version 分支为保护分支，不允许直接推送，只能通过merge不允许直接提交代码，接受MR。
bug修复
需要修改bug时，从release-$version新拉分支，修改完成后再合并到release-$version分支.
-
Q: 从
release-$version拉的分支，如何测试？ -
A: 这个节点定义为bug修复节点，建议开发同学优先本地测试验证，严重通过再合并到release分支。
-
Q:
release-$version太多怎么办？ -
A: 可以保留最近的10个版本。历史的打tag后，删除分支。
感谢您的认真阅读。
如果你觉得有帮助，欢迎点赞支持！
不定期分享软件开发经验，欢迎关注作者, 一起交流软件开发：
