专栏首页JadePeng的技术博客高效团队的gitlab flow最佳实践

高效团队的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,按照版本发布的模式实施,具体来说:

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

提交代码后,可以提交mrmaster,申请合并代码

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.

设定release-$version 分支为保护分支,不允许直接推送,只能通过merge不允许直接提交代码,接受MR

bug修复

需要修改bug时,从release-version新拉分支,修改完成后再合并到release-version分支.

  • Q: 从release-$version拉的分支,如何测试?
  • A: 这个节点定义为bug修复节点,建议开发同学优先本地测试验证,严重通过再合并到release分支。
  • Q: release-$version太多怎么办?
  • A: 可以保留最近的10个版本。历史的打tag后,删除分支。

感谢您的认真阅读。

如果你觉得有帮助,欢迎点赞支持!

不定期分享软件开发经验,欢迎关注作者, 一起交流软件开发:

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 架构师分享 高效团队的gitlab flow最佳实践

    当前git是大部分开发团队的首选版本管理工具,一个好的流程规范可以让大家有效地合作,像流水线一样有条不紊地进行团队协作。

    IT大咖说
  • gitflow 开发流程 转

    目前有专业提供gitflow开发流程的开发工具 SourceTree,推荐大家可以用用,mac和windows客户端都有的。

    henrylee2cn
  • Gitflow branch与Docker image tag命名冲突怎么办?

    在前公司,我根据主流的git flow 给团队搭建了一套devops流程,运行在 docker & k8s上。

    有态度的马甲
  • 【DevOps实践】企业应用场景众多,怎样选择合适的代码分支模型?

    常见的Git类代码分支模型有Git flow、Github flow、Gitlab flow、TBD等,企业可根据其业务、团队、管控等多方因素,选用其中一种或多...

    嘉为蓝鲸
  • Google 和腾讯为什么都采用主干开发模式?

    本文介绍了两种常用的代码分支模式:特性分支开发模式、主干开发模式,分别阐述了其优缺点和适用环境;同时剖析了 Google 和腾讯采用主干开发模式的背景和决策因素...

    深度学习与Python
  • 大揭秘| 我司项目组Gitlab Flow && DevOps流程

    现代Devops技术基于容器技术、自动化脚本实现了依赖环境的打包、版本管理、敏捷部署。

    有态度的马甲
  • ​「DevOps 转型与实践」沙龙回顾第一讲

    9 月 19 日,CODING 和中国 DevOps 社区联合举办的深圳第九届 Meetup 在腾讯大厦 2 楼多功能圆满结束。本次沙龙以 「DevOps 转型...

    CODING
  • 「DevOps 转型与实践」沙龙回顾第一讲

    9 月 19 日,CODING 和中国 DevOps 社区联合举办的深圳第九届 Meetup 在腾讯大厦 2 楼多功能圆满结束。本次沙龙以 「DevOps 转型...

    CODING
  • GitLab版本控制与协作最佳实践

    行业的快速变化以及客户对新功能的需求不断增加,可能导致团队孤岛工作。应用程序开发需要速度和迭代,因此无缝协作是交付业务价值的必要条件。团队转向版本控制来简化协作...

    DevOps云学堂
  • 浅谈基于 Git 的版本控制工作流

    博主说:本文借鉴了很多「 DRPrincess」博主的文章内容,在此对其表示感谢。

    CG国斌
  • 浅谈基于 Git 的版本控制工作流

    因此,在本文中,我们就从「[版本控制简史」出发,揭开「基于 Git 的版本控制工作流」的神秘面纱。

    CG国斌
  • 图文讲解,团队开发中的 Git 最佳实践

    在 2005 年的某一天,Linux 之父 Linus Torvalds 发布了他的又一个里程碑作品——Git。它的出现改变了软件开发流程,大大地提高了开发流畅...

    芋道源码
  • 团队开发中的 Git 实践

    本文转载自:https://segmentfault.com/a/1190000004963641[1]

    小小詹同学
  • 团队开发中 Git 最佳实践,不给队友拖后腿!

    本文要从具体实践角度,尤其是在团队协作中,阐述如何去好好地应用 Git。既然是讲在团队中的应用实践,我就尽可能地结合实际场景来讲述。

    江南一点雨
  • 团队开发中 Git 最佳实践,不给队友拖后腿!

    本文要从具体实践角度,尤其是在团队协作中,阐述如何去好好地应用 Git。既然是讲在团队中的应用实践,我就尽可能地结合实际场景来讲述。

    GitHubDaily
  • Git Workflow简介

    Git Flow是构建在Git之上的一个组织软件开发活动的模型,是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套...

    mantou
  • 用 GitLab 的 Merge Request 做代码评审

    在目前已使用的质量内建的工程实践中不可否认的一个实践为代码审查 它被用作提高产品交付质量和提高开发过程效率的有效措施。

    DevOps时代
  • 如何在团队中做好Code Review

    想要做好Code Review,必须让参与的工程师充分认识到Code Review的好处

    KenTalk
  • 基于 git flow + gitlab 协作开发:01

    很久以来,我一直在寻找一个适合小型团队独立项目的 git 协同工作流。主要原因是实际工作中很难在繁忙的迭代中兼顾真正的协同和代码质量管理。造成的现象就是在一个以...

    我与梦想有个约会

扫码关注云+社区

领取腾讯云代金券