发布管理要保证版本可追踪、变更可解释、问题可回滚。
Git 本身负责记录版本历史，GitHub Release、tag、changelog、CI/CD 则把这些历史变成可交付的版本资产。
merge -> tag -> release notes -> deploy -> verify -> announce
推荐使用语义化版本：
v2.0.0
v2.0.1
v2.1.0
常见含义：
至少包含：
hotfix 只处理生产环境紧急问题。
原则：
流程见 Hotfix Process。
Netflix Spinnaker 这类公开实践提醒我们，很多团队真正的风险集中在发布过程，分支模型只是其中一部分。
当团队已经有 PR、CI 和分支保护后，下一步要补的是：
详细见 Netflix Spinnaker 与发布流水线实践。
Microsoft Release Flow 的经验适合有固定 sprint、固定发布窗口的团队：
Slack 公开分享的部署实践更强调“持续小批量发布”：通过自动化检查、发布队列、可观测性和回滚路径，把风险拆散到日常部署中处理。
这两类实践方向不同，但共同点很清楚：发布管理不能只依赖分支命名，要把验证、审批点、发布记录、监控和回滚路径串起来。
如果团队有固定发布窗口，可以优先参考 Microsoft Release Flow。如果团队高频部署，可以优先参考 Slack Deploys 和 Netflix Spinnaker。更多案例对照见 大厂工程实践决策图谱。