要删，但需确认版本已正式上线且无回滚需求；删除前应本地备份、远程归档至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/ 前缀下：
- 重命名远程分支：
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 后自动执行——后者无法判断是否真上线
