在 GitLab 版本管控中，管理 Release 分支和 Tags 是版本管控、交付稳定性和团队协作效率的核心环节。首先需要明确两者的本质区别、关联逻辑，再结合场景制定规范，最终落地可执行的管理策略。
一、核心概念：Release 分支 vs Tags（先理清定义）
1. Tags（标签）——「不可变的版本快照」
- 本质：是指向某个具体提交（commit）的「永久指针」，不可修改（轻量标签）或附带元数据（附注标签），是版本的「唯一标识」。
- 核心特性：
- 不可变：一旦创建，标签本身不随代码变动（除非强制删除重建，严禁这么做）；
- 轻量化/附注型：轻量标签仅存 commit 哈希，附注标签可包含版本说明、负责人、changelog 等（推荐用附注标签）；
- 无分支特性：不占用分支空间，仅标记特定提交。
2. Release 分支（发布分支）——「可迭代的交付分支」
- 本质：是从开发分支（如
develop）分出的「临时/长期分支」，专门用于某一版本的最终测试、Bug 修复和发布准备。 - 核心特性：
- 可修改：允许在分支上修复发布前的小 Bug（不引入新功能）；
- 生命周期：对应具体版本（如
release/1.2.0），发布完成后可归档或删除； - 隔离性：隔离开发分支的新功能，避免未完成代码影响发布。
3. 两者的核心关系
| 维度 | Release 分支 | Tags |
|---|---|---|
| 核心作用 | 发布前的「准备与修复」 | 发布后的「版本固化与追溯」 |
| 可修改性 | 允许小 Bug 修复（迭代） | 不可修改（快照） |
| 生命周期 | 版本发布后可归档/删除 | 永久保留（作为版本唯一标识） |
| 关联逻辑 | Release 分支稳定后，在其最终提交上打 Tag | Tag 是 Release 分支「交付成果的最终标记」 |
简单说：Release 分支是「过程」，Tags 是「结果」 —— 先通过 Release 分支完成版本的最终打磨，再在该分支的最终提交上打 Tag，作为这个版本的正式发布标识。
二、核心场景：什么时候用？
1. Release 分支的适用场景
Release 分支的核心价值是「隔离发布准备」，主要用在以下场景：
- 正式版本发布前的稳定化：
当开发分支（
develop）完成某一版本的功能开发，需要进入「测试 - 修复 - 验证」阶段时，分出 Release 分支（如release/1.2.0），所有发布前的 Bug 修复都在这个分支上做，避免开发分支的新功能代码污染发布版本。 - 多版本并行维护：
比如线上运行
1.1.x版本，同时开发1.2.0版本，若1.1.x需要紧急修复，可基于1.1.0的 Tag 创建release/1.1.1分支，修复后发布并打新 Tag。 - 灰度发布/预发布验证：
基于 Release 分支部署预发布环境，验证稳定性，修复问题后合并到
main（主分支）和develop（开发分支），保证主分支和开发分支同步修复。
2. Tags 的适用场景
Tags 是版本的「法定标识」，核心用在以下场景：
