高效的Gitlab Flow最佳实践

高效的Gitlab Flow最佳实践

引用

CSDN

1.

https://blog.csdn.net/u011436427/article/details/136843310

在软件开发中，Git工作流程的选择对于团队协作效率和代码质量有着重要影响。本文将详细介绍三种主流的Git工作流程：Git flow、GitHub flow和Gitlab flow，并重点介绍Gitlab flow的最佳实践。

一、Git flow

最早诞生并得到广泛采用的一种工作流程就是Git flow。它定义了两个长期分支：

• 主分支（master）：存放对外发布的稳定版本
• 开发分支（develop）：存放最新的开发版本

此外，还有三种短期分支：

• 功能分支（feature branch）
• 补丁分支（hotfix branch）
• 预发分支（release branch）

缺点：

• 单独使用Git flow命令管理较为复杂
• 运行起来过于复杂

二、GitHub flow

GitHub flow采用单一主分支（master）策略，流程简单直观：

1. 根据需求从master拉出新分支
2. 开发完成后发起Pull Request
3. 通过代码评审和讨论后合并到master
4. 重新部署后删除原分支

缺点：

• 对代码贡献者的素质要求较高

三、Gitlab flow

Gitlab flow结合了Git flow和GitHub flow的优点，采用"上游优先"原则：

1. 持续发布模式：适用于持续集成/持续部署（CI/CD）场景

• master分支：开发环境

• pre-production分支：预发环境

• production分支：生产环境

• 代码变化必须由上游向下游发展

  

2. 版本发布模式：适用于定期发布新版本的项目

• 每个稳定版本从master分支拉出独立分支（如2-3-stable）

• 仅在需要修补bug时合并代码，并更新小版本号

  

四、基于Gitlab flow的最佳实践

采用Gitlab flow，按照版本发布的模式实施：

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

1. 语义化版本号

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

• 主版本号：当你做了不兼容的 API 修改，
• 次版本号：当你做了向下兼容的功能性新增，
• 修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。主版本号为0，代表还未发布正式版本。

2. 测试发布

• master分支，自动部署到开发环境（dev）
• 功能开发完成，并自测通过后，代码合并到待发布版本
• 分支规则：release-$version
• 版本规则：主版本号.次版本号.修订号
• 从最新的master新拉一个分支release-$version，比如release-0.1.1
• 设定release-$version 分支为保护分支，不允许直接推送，只能通过merge不允许直接提交代码，接受MR。

3. bug修复

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

常见问题：

• 从release-$version拉的分支，如何测试？建议开发同学优先本地测试验证，严重通过再合并到release分支。
• release-$version太多怎么办？可以保留最近的10个版本。历史的打tag后，删除分支。