原文链接：
Slack 的发布实践适合补充“merge 之后发生什么”。
很多 Git 教程写到 PR 合并就结束了，但企业协作链路真正的风险常常在发布阶段。
可以把 Slack 这类发布实践抽象成：
PR
-> review
-> tests
-> merge
-> release branch
-> staging
-> dogfood
-> canary
-> percentage rollout
-> rollback / hotfix
不同团队的工具不同，但核心目标一致：发布要可控、可观察、可回滚。
Git 负责记录变更事实：
发布系统负责控制变更进入用户环境：
这两套系统必须能互相追溯。
Release Management 不能只写 GitHub Release 和 tag。
还要写发布过程里的验证、灰度、回滚、hotfix 和发布记录。