当前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这种方式，要保证高质量，对于贡献者的素质要求很高，换句话说，如果代码贡献者素质不那么高，质量就无法得到保证。
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-$version拉出分支进行修复，修复完成后，再合入release-$version
- 正式发布版本，如果上线后，又有bug，根据5的方式处理
- 等发布版本稳定后，将release-$version反合入主干
最佳实践#
开发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后，删除分支。
几个注意的点
1.在gitlab中将主仓库fork到个人仓库
- Fork 出来的仓库完全属于你自己，你可以任意修改该仓库的代码及配置，但是除非你向项目主仓库提交 pull request，并且被接受通过，你才可以将你fork 仓库修改的代码合并到主仓库，否则不会对主仓库产生任何影响。
- 一般来讲，
pull代码，需要从主仓库拉取最新的代码；push的话，则只能严格推送到个人的子仓库。这里需要在gitlab中做好权限的分配（这是管理工作）。
2.保持个人仓库和 upstream 同步
- 这里需要注意，建议每天开发工作开始前，将
upstream的代码更新到本地
发起 pull request 或 merge request > - github -> pull request > - gitlab -> merge request > 1. 在 gitlab 的个人仓库页面的左边菜单点击merge request (👋记住是个人仓库)
