发布打标签流程
发布打标签是一套有先后顺序的动作：确认发布分支与版本号，打附注标签，推送标签，触发流水线，最后生成发布说明。标签把「某个发布版本」锚定到具体提交，是回溯问题、切补丁分支、核对制品的共同起点。
基本信息
| 顺序 | 分支确认 → 打标签 → 推送标签 → 流水线 → 发布说明 |
|---|---|
| 标签类型 | 附注标签 -a；需要验证来源时用签名标签 -s |
| 触发方式 | 推送匹配规则的标签触发流水线（tag 触发） |
| 追溯依据 | 标签唯一指向发布提交，与制品版本号一一对应 |
典型使用场景
- 常规版本发布，需要可追溯的发布点
- hotfix 修复后发补丁版本，重新打标签而不是复用旧标签
- 标记预发布与候选版本，与正式版本区分
- 按标签构建制品，保证构建可复现
- 生成发布说明时列出标签之间的提交
常用示例
常用示例
git switch release/2.4.0 && git pull --ff-only # 确认在发布分支且与远端一致
git log --oneline v2.3.0..HEAD | head # 预览本次发布包含的提交
git tag -a v2.4.0 -m 'release 2.4.0' # 打附注标签
git push origin v2.4.0 # 推送标签触发流水线
git show v2.4.0 --stat | head # 核对标签指向的提交与改动
git tag --contains $(git rev-parse v2.4.0) # 确认标签落在预期提交上步骤与失败处理
| 步骤 | 失败表现 | 处理方式 |
|---|---|---|
| 分支确认 | 分支落后或指向错误提交 | 先 pull --ff-only 再重新确认 |
| 打标签 | 标签名已存在 | 改用新版本号，不复用已发布标签 |
| 推送标签 | 被规则或权限拒绝 | 核对标签保护规则与账号权限 |
| 流水线 | 构建失败 | 修复后打新版本号，不移动旧标签 |
标签推送成功后再对外宣布发布；标签推送失败时流程应中断并告警，避免出现「已宣布但没有制品」的版本。
发布前把标签与制品一起留档：记录标签名、构建编号与部署时间的对应关系，线上出问题时能立刻确认当前运行的是哪一次构建，而不是靠人回忆。