基于gitlab适用于版本发布的git-flow团队开发协作规范

最新推荐文章于 2024-06-24 23:41:59 发布
最新推荐文章于 2024-06-24 23:41:59 发布
阅读量343 收藏
点赞数 1
CC 4.0 BY-SA版权
文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/BASK2312/article/details/129024037
本文详细介绍了Git的分支管理与协作流程，包括LTS版本的支持，MergeRequest(MR)和PullRequest(PR)的使用，以及master、develop、feature、bugfix、test和hotfix等不同分支的角色和合并规则。同时，文章还阐述了开发、bugfix、hotfix的处理流程及其在不同分支上的操作步骤，以及发版流程的特别注意事项。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

名词解释

  • LTS版本：Long Term Support长期支持版本，简称LTS。

  • MR/PR：是Merge Request/Pull Request，我们常说的提PR的意思是开发人员在某个分支功能开发完了，需要发送一个请求，请求将某个源分支代码合并到目标分支，这个过程为了让项目组长/负责人进行code review（代码审查），check没有问题之后允许合并。

分支规范

一共拥有以下几个（种）branch：

分支

描述

master

master上的都是production-ready的stable的代码

develop

作为开发的主分支， 所有的merge操作都应该先合并到develop分支，再定期merge到master 发版

release-xxx

LTS版本需要有独立的branch，以作为后续（万一）hotfix使用，精确到minor version，如release-v1.2，为长期保留的分支。

feature/xxx

所有新的feature（如新功能、性能优化）都应当先checkout到一个新的feature分支开发，原则上必须且只能merge到develop分支

bugfix/xxx

bug的修复分支，原则上必须且只能merge到develop分支

test/xxx

test分支主要做以下三件事：1. 增加unit test；2. 修改仓库级别配置文件（如.gitlab-ci.yml）；3. 用来承载一些一次性的测试（最好不合并入develop）

hotfix/xxx

用来发布hotfix的分支，大多是用于承载线上比较紧急的bug修复

release/xxx

用来做发版工作（如更新版本号，bugfix）的分支，还有一个作用是freeze feature, 不允许合入feature，只允许合入bugfix

协作流程

开发流程

  1. 首先，确认自己在develop分支上，基于开发分支切一个功能分支出来；

  1. git checkout -b feature/your_feature；

  1. 开发完成后，push到origin；

  1. 提pr（如果是性能优化，请在description中附带上benchcmp的结果），target branch为develop，并勾选最下方两个选项：

  1. 等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选：

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge：

7.done(完成)

bugfix 流程

develop上的bugfix

  1. 首先，确认自己在develop分支上；

  1. git checkout -b bugfix/your_bugfix；

  1. 开发完成后，push到origin；

  1. 提mr，target branch为develop，并如开发流程一样勾选最下方两个选项；

  1. 等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；

  1. done(完成)。

release/xxx上的bugfix

这里不需要直接merge回develop是因为release/xxx最终会merge回develop。

  1. 首先，确认自己在release/vX.Y.Z分支上；

  1. git checkout -b bugfix/your_bugfix；

  1. 开发完成后，push到origin；

  1. 提mr，target branch为release/vX.Y.Z，并如开发流程一样勾选最下方两个选项；

  1. 等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；

  1. done(完成)。

hotfix 流程

需要merge到develop

  1. 按照 普通bugfix流程 完成bug修复，记得要更新代码中的版本号（为了防止merge到master后忘记 merge回develop）；

  1. 切换到master分支上；

  1. git checkout -b hotfix/your_hotfix；

  1. cherry-pick bugfix的commit；

  1. 检查无误后，push到origin；

  1. 提mr，target branch为master，并如开发流程一样勾选最下方两个选项；

  1. 等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；

  1. 切换到master分支上，打一个新的tag；

  1. done(完成)。

仅需要merge到master

适用于需要修复的bug在develop分支上已不存在的情况。

版本号的更新不需要同步到develop，在下次merge的时候解决冲突即可。

  1. 首先，确认自己在master分支上；

  1. git checkout -b hotfix/your_hotfix；

  1. 修复完成后，新增一个独立的commit，更新代码中的版本号，push到origin；

  1. 提mr，target branch为master，并如开发流程一样勾选最下方两个选项；

  1. 等待review通过，通过后点击 merge，请再次确认squash和delete branch被勾选；

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；

  1. 切换到master分支上，打一个新的tag；

  1. 将第三步中更新版本号的独立的commit cherry-pick到develop分支上；

  1. done(完成)。

需要merge到LTS release branch

  1. 根据情况，完成需要merge到develop或者仅需要merge到master中的一个；

  1. 切换到release-vX.Y.Z分支上（待修复的分支）；

  1. git checkout -b hotfix/your_hotfix；

  1. cherry-pick hotfix的commit；

  1. 更新代码中版本号，检查无误后，push到origin；

  1. 提mr，target branch为release-vX.Y，并如开发流程一样勾选最下方两个选项；

  1. 等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；

  1. 切换到release-vX.Y.Z分支上，打一个tag；

  1. done(完成)。

发版流程

发版流程比较特殊，和其它流程有较大区别，请注意细节。

这么做的原因是，如果先把release branch merge到develop分支上，再将develop分支merge进master 的话，可能会带上预料之外的commit（在整理release的时候有新的mr被merge到develop）。

  1. 首先，确认自己在develop分支上；

  1. git checkout -b release/vX.Y.Z；

  1. 做一些发版需要的工作（如更新版本号等）；

  1. 完成后，push到origin；

  1. 提mr，target branch为master，不勾选 suqash 和 remove source branch；

  1. 等待review通过，通过后点击merge，请再次确认 squash 和 delete branch 未被勾选；

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；

  1. 切换到master，打一个vX.Y.Z的tag。

  1. 再提一个mr，target branch为develop，不勾选 suqash 和 remove source branch；

  1. 等待review通过，通过后点击 merge，请再次确认 squash 和 delete branch 未被勾选；

  1. 如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；

  1. done(完成)。

总结

实际上，每个公司的团队协作gitflow可能都不太一样，甚至有些小公司没有这方面的多人协作管理，然而我仅仅总结了以往公司已经借鉴的Git的gitflow规范得出以上内容，文章全部介绍就到这里了，如果文章对你有所帮助，欢迎 点赞 👍 +评论 💬 +收藏 ❤ ，我是： 👨 ‍austin流川枫，我们下期见!

作者：austin流川枫

链接：https://juejin.cn/post/7199192593279991867

GitLab使用规范
莫奈小姐姐的博客
02-25 1366
一、Gitlab flow管理流程说明 我们选择使用的是Gitlab flow管理流程，他是功能驱动式开发（Feature-driven development，简称FDD）。 需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。 Gitlab flow的最大原则叫做上游优先（upsteam first），即只存在一个主分支master，它是所有其他分支的上游。只有上游分支采纳的代码变化，才能应用到其
Github flow和GitLab flow工作流及规范
niwoxiangyu的博客
07-02 882
开发工作流规范化 选型 规范的开发工作流程对于团队项目的良性推进是至关重要的。当前主流的基于Git的项目开发工作流有Git Flow和GitHub Flow、Gitlab Flow。 Git Flow围绕项目发布定义了非常严格的分支模型，本身比较复杂，但为管理大规模项目提供了坚实的框架， 适合50及以上数量参与者的大型项目。 GitHub Flow则是一个轻量级的基于分支的工作流，非常适合代码快速频繁迭代和部署，项目成员20人以内的小型团队。 ...
浅析GitLab Flow的十一个规则
weixin_33937499的博客
08-17 207
 使用 Git 版本控制，是对使用它之前的所有版本控制方式的一种改进。然而，很多组织最终以太过混乱或过于复杂的流程来结束。这个问题对于刚从其他版本控制系统转过来的组织来说特别突出。 在本文中我们会列出 GitLab 工作流 的11条规则，以帮助简化、整理工作流程。这些规则最主要的益处是(或我们希望是) 它能够简化流程并且产生一个更高效和更清楚的成果。 我们认为总会有可改善的空间，并且每一次...
GitLab Flow 的 11 条规则
weixin_33843409的博客
05-18 216
使用 Git 进行版本管理，是对 Git 之前所有方法的改进。然而，很多组织最终会出现凌乱的工作流程，或过于复杂的工作流程。这问题对于从另一版本控制系统转换过来的组织来说尤为突出。 本文中，我们为 GitLab 工作流程制定了11条规则，以帮助简化和清晰。规则的主要好处（或者说我们希望的好处）是它简化过程，并产生更加有效和更清晰的结果。 总是存在改善...
【Git】git-flow多人开发git各个分支的职责与用法
男人只说三分话、留得七分打天下。
12-26 750
git-flow也叫做git的工作流程图吧，是git分支的一种模型化，同时也规定了开发的一些规则。面向开发用的分支，代码安定，开发并测试合格后（达到可发布状态）合并到release分支。新机能开发用的分支，开发前从develop分支切出，开发后再合并到develop分支。明确规定各个分支的职能，与操作规则，可以有效防止多人同时开发造成分支混乱的问题出现。在这个分支上进行发布前测试，没有问题之后合并到master和develop分支。面向产品发布用的分支。用来准备向生产环境发布用的代码的分支。
一文弄懂 Gitflow、Github flow、Gitlab flow 的工作流
p1830095583的博客
05-21 3229
Git 作为一个源码管理系统，不可避免涉及到多人协作。 协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。”工作流程”在英语里，叫做”workflow”或者”flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。 本文介绍三种广泛使用的工作流程： Git flow Github flow Gitlab flow 一、功能驱动 本文的三种工作流程，有一个共同点：都采用”功能驱动式开发”（Feature-driven developmen
Git与GitLab的企业实战--尚硅谷git课程
最新发布
温涛的博客
06-24 1258
Git与GitLab的企业实战--尚硅谷2024git课程 加上一些自己在工作上常用的命令
Laravel开发-gitlab-flow
08-27
Gitlab Flow是一种版本控制策略，它基于Gitflow，但更加强调自动化和持续集成/持续部署(CI/CD)实践。通过这个包，开发人员可以轻松地利用Gitlab的特性，如MR（Merge Request）和CD流程，从而提高团队协作和代码质量...
GitLab 工作流介绍（GitLab Flow）
热门推荐
纠缠AI的亮子
09-01 3万+
先上官方文档链接： GitLab Flow
Git、GitFlow协作 、Git commit规范、语义化版本
Jason的技术探索与分享
06-03 1066
本文将介绍Git（安装、配置、基本操作、冲突解决 ）、GitFlow协作、Git提交规范、语义化版本。git gitlab gitflow关系：git 是一种版本控制系统；gitlab是一个基于Git实现的在线代码仓库软件；gitflow工作流定义了一个围绕项目发布的严格分支模型，它为不同的分支分配了明确的角色，并定义分支之间何时以及如何进行交互。语义化版本SemVer是认可度最高的软件版本规范。它是由Gravatars创办者兼 GitHub 共同创办者。
使用gitlab做git flow及代码审查
master_yao的博客
11-24 5354
使用gitlab做git flow及代码审查
gitLab管理多个远程git repo,版本管理和发布流程的设计
wangduqiang747的博客
01-16 335
先留着占个位子,年后写。
Git超实用管理框架——Git Flow、GitHub Flow、GitLab Flow工作流程详解
Trisyp的博客
07-28 2500
之前一直在用git，但仅仅只是在自己的分支push和pull，用的也是GUI来提交，没有想那么多，可是突然称为一个管理者的时候发现git项目管理还是很重要的，对于Git常用命令是个程序员都不用多说什么，大家肯定信手拈来，但对于技术团队，还是需要用较为规范的 Git操作流程。 Git最重要的概念就是分支（fork），而操作流程的复杂度也取决于分支的个数和提交的复杂度。最大而全的框架就是Git Flow了，分支较多，非常适用于版本发布的工作流程。但不太适合持续发布（代码部署非常频繁）的开发场景。所以GitHu
Git 工作流程（Git Flow、GitHub Flow、GitLab Flow）
77wpa的博客
08-14 1338
Git 分支管理1. 常见 Git 分支管理1.1 单主干1.2 GitHub flow1.3 Git flow 1. 常见 Git 分支管理 Git 是目前最流行的源代码管理工具，本文将介绍三种常见的 Git 分支管理方式。 1.1 单主干 单主干的分支实践（Trunk-based development，TBD）在 SVN 中比较流行。 Google 和 Facebook 都使用这种方式。trunk 是 SVN 中主干分支的名称，对应到 Git 中则是 master 分支。TBD 的特点是所有团队成员都
Git协作流程详解
Be The Best！
12-30 1067
Git 作为一个源码管理系统，不可避免涉及到多人协作。 本文介绍三种广泛使用的协作流程： Git flow Github flow Gitlab flow
团队项目的Git分支管理规范
06-18 426
原文地址：http://blog.jboost.cn/git-branch.html 许多公司的开发团队都采用Git来做代码版本控制。如何有效地协同开发人员之间，以及开发、测试、上线各环节的工作，可能都有各自的流程与规范。本文分享的是作者一直沿用的团队项目Git分支管理规范，希望给有缘阅读的人以参考，如果有更好的实践，也欢迎探讨、交流。 分支管理 创建项目时（一般是服务型项目，工...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值