要删，但需确认版本已正式上线且无回滚需求；删除前应本地备份、远程归档至archive/命名空间，并确保tag在合并前签发以保证代码一致性。

release 分支发布后要不要删？

要删，但得等确认 release 已正式上线且无回滚需求。Git 本身不强制清理，但不删会堆积冗余分支，干扰 git branch -a 输出，也容易让新成员误切错分支。

典型错误是：打完 tag、推送到远程后立刻执行 git branch -d release/1.2.0，结果发现线上出问题需要紧急热修——此时已无法快速检出该分支做 hotfix。

• 必须等 release 对应的 tag 被部署验证通过（比如监控确认 5 分钟内无报错）
• 确认该版本没有 pending 的 hotfix PR 或未合并的修复 commit
• 删除前先本地备份： git checkout release/1.2.0 && git tag backup/release-1.2.0
• 远程删除用 git push origin --delete release/1.2.0，不要只删本地

归档分支该不该保留在远程仓库？

不该长期保留，但可阶段性归档到专用命名空间。直接留着 release/1.2.0 这类分支名，会和正在开发的 release/1.3.0 混在一起，git branch --merged master 也筛不出有效分支。

更稳妥的做法是统一迁移到 archive/ 前缀下：

GitHub Actions Runtime Regression Audit

对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。

下载

• 重命名远程分支：git push origin :release/1.2.0 && git push origin refs/heads/release/1.2.0:refs/heads/archive/release-1.2.0
• 这样既保留历史可追溯性，又从日常分支列表中隔离出来
• CI 脚本里若硬编码了 release/* 匹配，记得同步更新 glob 规则

tags 和 release 分支的关系容易搞混

tags 是不可变锚点，release 分支是可修改的交付线。很多人以为打了 v1.2.0 tag 就等于 release 完成，其实 tag 只是快照标记，分支上可能还有后续的 patch commit（比如修复打包脚本问题）。

关键区别：

• git tag v1.2.0 指向某次 commit，之后不能再改；release/1.2.0 分支指针可以向前移动
• CI 构建产物应基于 tag（如 git archive v1.2.0），而不是分支名，否则可能打包到分支上未合入的临时修改
• GitHub/GitLab 的 Release 页面展示的是 tag + 描述，不是分支；分支只是辅助生成 tag 的过程载体

自动化归档脚本要注意的坑

用 GitHub Actions 或 Jenkins 自动删分支时，git push --delete 成功不代表远端分支真正消失——某些托管平台（如 GitLab CE）有异步清理延迟，紧接着执行 git ls-remote --heads origin release/1.2.0 可能仍返回旧引用。

• 加 2 秒 sleep 再校验，或改用 git ls-remote origin | grep -q 'release/1.2.0' 循环等待
• 避免在同一个 job 中先删分支再基于同名分支触发新 job，Git 服务器缓存可能导致误判
• 归档操作必须有明确 owner，比如由发布人手动触发，而非 merge 到 main 后自动执行——后者无法判断是否真上线

实际交付中最容易被忽略的，是 release 分支生命周期与 tag 签发时机的错位：tag 应该在分支最后一次合并进 main 之前打，而不是之后。否则，main 上合入的那次 merge commit 本身就不在 tag 范围内，导致构建产物和线上实际运行的代码不一致。