当前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，按照版本发布的模式实施，具体来说：

1. 新的迭代开始，所有开发人员从主干master拉个人分支开发特性, 分支命名规范 feature-name
2. 开发完成后，在迭代结束前，合入master分支
3. master分支合并后，自动cicd到dev环境（这一步是开发自测）
4. 开发自测通过后，从master拉取要发布的分支，release-$version，将这个分支部署到测试环境进行测试
5. 测出的bug，通过从release-$version拉出分支进行修复，修复完成后，再合入release-$version
6. 正式发布版本，如果上线后，又有bug，根据5的方式处理
7. 等发布版本稳定后，将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 (👋记住是个人仓库)