git中无需为每个版本保留冷备分支，因标签（如v1.2.0）已轻量、不可变地锚定发布状态；冷备分支易漂移、增维护成本，仅当需并行维护多生产版本、满足强制审计或部署系统不支持tag时才需创建。
没必要为每个版本单独保留冷备分支，除非你明确需要长期维护多个并行版本或应对特定合规审计要求。
冷备分支 ≠ 发布标签（v1.2.0）
很多人混淆了「保留分支」和「打标签」。Git 的 git tag -a v1.2.0 已完整锚定发布时的代码状态，且不可变、轻量、不占用额外合并历史。而冷备分支（如 release/v1.2.0）是一个可移动指针，容易被误操作修改，还可能因长期不更新引入意外冲突。
- 标签（
tag）只记录一个 commit，适合归档与快速回溯 - 分支（
release/v1.2.0）会随后续git push漂移，除非严格禁写 - CI/CD 系统通常只依赖 tag 触发构建，不认 release 分支
什么情况下真需要冷备分支？
只有满足以下至少一项时，才值得开销维护冷备分支：
- 你正在同时维护 3 个以上生产版本（如 v1.x、v2.x、v3.x），且各版本需独立 hotfix
- 客户合同强制要求「每个 GA 版本必须有独立可 checkout 的分支」用于第三方审计
- 你的部署系统无法基于 tag 部署，只能基于分支名拉取（这类系统应优先改造）
注意：hotfix/* 分支本身是从 main（或 master）派生的，修复后会合并回 main 和 develop，并不依赖冷备分支存在。
误留冷备分支的实际代价
看似“多留无害”，但真实成本常被低估：
- GitHub/GitLab 的分支列表变长，PR 自动补全和搜索效率下降
- CI 流水线默认扫描所有分支，未配置过滤会导致无效构建任务堆积
- 新成员 clone 仓库后看到几十个
release/*分支，第一反应是“该删哪个？” - Git 历史图谱（
git log --graph）被大量孤立分支干扰，关键路径难识别
真正该做的是：确保 main 始终可部署，每个发布都打语义化标签（v2.4.1），并用 CI 自动归档二进制产物到对象存储——这些比冷备分支更可靠、更轻量、更易自动化。
