当前git是大部分开发团队的首选版本管理工具，一个好的流程规范可以让大家有效地合作，像流水线一样有条不紊地进行团队协作。
业界包含三种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，通过从 master 拉出分支(上游优先原则)，进行修复，修复完成后，先合并到 master，再通过 cherry-pick 或者 patch 合入 release-$version 。
- 正式发布版本，如果上线后，又有 bug，根据5的方式处理。
最佳实践
开发feature功能
新建分支，比如feat-test
开发代码，增加新功能，提交：
|
1 2 3 4 5 |
@GetMapping(path = "/test", produces = "application/json") @ResponseBody public Map<String, Object> test() { return singletonMap("test", "test"); } |
|
1 2 3 |
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）
功能开发完成，并自测通过后，代码合并到待发布版本，
分支规则：
|
1 |
release-version |
版本规则
|
1 |
主版本号.次版本号 |
构建时，自动增加修订号：
|
1 |
主版本号.次版本号.修订号 |
从最新的master新拉一个分支release-$version，比如release-0.1
|
1 |
$ git checkout -b release-0.1 |
release-$version会自动构建，版本号为$version.$buildNumber
设定release-$version 分支为保护分支，不允许直接推送，只能通过merge不允许直接提交代码，接受MR。
bug修复
需要修改 bug 时，从master新拉分支(上游优先原则)，修改完成先合并 master 再通过 cherry-pick 或者 patch 合并到release-$version分支。
-
Q: 从
master拉的分支，如何测试？ -
A: 这个节点定义为 bug 修复节点，建议开发优先本地测试验证，验证通过再发起合并请求到 master/release 分支。
-
Q:
release-$version太多怎么办？ -
A: 可以保留最近的10个版本。历史的打 tag 后，删除分支。