gitlab版本_一种基于 gitlab 的适用于版本发布的 gitflow 协作规范

最新推荐文章于 2024-05-17 10:13:07 发布

weixin_39612554

最新推荐文章于 2024-05-17 10:13:07 发布

阅读量323

点赞数

文章标签： gitlab版本

本文链接：https://blog.csdn.net/weixin_39612554/article/details/113074087

版权

本文介绍了一种基于GitLab的版本发布Gitflow协作规范，详细阐述了Branch规范、开发流程、bugfix流程、hotfix流程以及发版流程。在每个流程中，强调了不同类型的分支（如master、develop、feature、bugfix等）的使用和合并规则，确保版本管理和协作的高效性。

摘要由CSDN通过智能技术生成

最近自己搞了一个基于 gitlab 的适用于版本发布(非持续集成)的脱胎于 git-flow 的协作规范，发布出来大家可以作为借鉴。

Branch 规范

一共拥有以下几个(种)branch：

master：master 上的都是 production-ready 的 stable 的代码。
develop：作为开发的主分支，所有的 mr 都应当(先)合并到 develop 分支，定期 merge 到 master 发版。
release-*：LTS 版本需要有独立的 branch，以作为后续(万一)hotfix 使用，精确到 minor version，如 release-v1.2，为长期保留的分支。
feature/*：所有新的 feature(如新功能、性能优化)都应当先 checkout 到一个新的 feature 分支开发，原则上必须且只能 merge 到 develop 分支。
bugfix/*：bug 的修复分支，原则上必须且只能 merge 到 develop 分支。
test/*：test 分支主要做以下三件事：1. 增加 unit test；2. 修改仓库级别配置文件(如 .gitlab-ci.yml)；3. 用来承载一些一次性的测试(不合入 develop)。
hotfix/*：用来发布 hotfix 的分支，详见下节。
release/*：用来做发版工作(如更新版本号，bugfix)的分支，还有一个作用是 freeze feature，不允许合入 feature，可以合入 bugfix，详见下节。

branch name 应当采用下划线命名法。会在 ci 中对于 branch name 做强制检查，如果不合规会直接 fail。留出 test/* 的 branch 也是为了能够支持一些测试性的工作能够通过 ci 检查。

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

2、git checkout -b feature/your_feature；

3、开发完成后，push 到 origin；

4、提 mr(如果是性能优化，请在 description 中附带上 benchcmp 的结果)，t

关注