Steam 发售候选分支治理实战：2021 年 5 月个人游戏如何冻结、验证和合并发布代码

候选分支的意义

个人开发者很容易在发售前持续往主分支加内容：修一个 bug，顺手改一段 UI，再加一个小功能，最后打包上传。问题是每个小改动都可能引入新风险。发售候选分支的意义，就是把“继续开发”和“准备发布”分开。

候选分支不是形式。它代表内容冻结、只接收经过判断的修复、每个构建都有编号、每次上传都能追溯。Steam 上线前最需要的是稳定，而不是最后一刻的灵感。

什么时候切候选分支

切候选分支的条件可以是：

• 主流程可通。
• 商店页承诺功能都存在。
• 关键平台构建能启动。
• 存档和设置系统稳定。
• 主线任务没有阻断问题。
• 已知 P0/P1 缺陷清零或有明确处理。

不要等所有小问题都修完才切候选。候选分支可以继续修 bug，但不再随意扩展内容。

分支命名

命名要清楚：

release/1.0.0-rc
hotfix/1.0.0-save-fix
develop
main

Steam 后台分支也要对应：

命名对应能减少上传错包的概率。

修复准入规则

进入候选后，哪些改动可以进？建议按级别判断：

规则要写下来。个人项目也会受到“顺手改一下”的诱惑，规则能帮你拒绝高风险改动。

构建编号和记录

候选构建记录要包含：

每个上传到 Steam 的候选包都要有记录。否则审核反馈或玩家测试反馈回来时，你不知道对应哪个包。

Steam internal 分支验证

候选包上传后，不要只运行本地构建。必须从 Steam 客户端安装 internal 分支验证：

• 安装目录是否干净。
• 启动项是否正确。
• Steam API 是否初始化。
• 云存档、成就、覆盖层是否工作。
• 构建编号和日志是否一致。
• 旧存档升级是否正常。

本地构建通过，不代表 Steam 分发包通过。Depot、分支、依赖和启动参数都可能出错。

回归范围

每次候选修复后，都要按修改点回归。修存档，测新旧存档；修输入，测键鼠和手柄；修本地化，测语言切换和 UI 溢出；修资源，测场景加载和 Steam 更新路径。

不要因为改动小就不回归。候选阶段的每个改动都应该有验证记录。

回滚判断

如果候选分支引入严重问题，要能回滚到上一个候选构建。回滚前判断：

• 上一个构建是否通过烟测。
• 当前改动是否影响存档格式。
• Steam 分支是否已经给外部测试者使用。
• 回滚后是否需要公告。

回滚不是失败，而是发布治理的一部分。比起继续在坏构建上叠修，回到稳定点往往更稳。

合并回主线

候选分支上的修复最终要合并回主线，避免发售后开发分支丢失修复。合并时要注意：候选分支可能没有新功能，而 develop 已经继续开发。合并要看冲突，不要盲目覆盖。

建议发售后做一次同步记录：哪些修复已进入 main，哪些还需要合并到 develop，哪些只针对发售版本。

发售前冻结日

发售前一天或几天设冻结日。冻结日后只接受 P0/P1。这个规则对个人开发者尤其重要，因为越接近发售越容易焦虑，想再改一点。临时改动带来的风险往往大于收益。

冻结日要做的是验证：Steam 分支、商店页、价格、公告、支持入口、日志、回滚方案。不是继续扩展内容。

最终检查清单

• 候选分支在主流程可通后切出。
• 内容冻结和修复准入规则明确。
• Git 分支和 Steam 分支命名对应。
• 每个候选构建有编号和记录。
• internal 分支通过 Steam 客户端验证。
• 每次修复按影响范围回归。
• 回滚目标和存档影响清楚。
• 发售前冻结日只处理阻断问题。

发售候选分支治理听起来像团队流程，但个人项目更需要它。一个人做决定时更容易凭感觉，流程能让 Steam 发布从“临时打包”变成可控交付。

候选分支的日常看板

候选阶段可以只维护一个很小的看板：阻断问题、待验证修复、已知可接受问题、发布前任务。不要把所有想做的优化都放进候选看板，否则优先级会失控。

这个看板帮助个人开发者在压力下保持范围。

已知问题的处理

候选版本可能仍有 P2/P3 问题。关键是记录和判断，而不是假装没有。已知问题要写清影响范围、是否有绕过方式、是否计划补丁。内部记录足够即可，不一定全部公开，但如果影响玩家购买或通关，就应该在公告或 FAQ 中说明。

审核反馈进入候选流程

Steam 审核反馈也要走候选流程。不要在收到反馈后直接改主分支再上传。应在候选分支修复，记录反馈编号、修改点、构建号和回归结果。这样如果审核再次询问，你能清楚说明处理了什么。

发布后打标签

正式发布的提交建议打标签或至少记录提交号。发售后如果要做热修，必须知道首发版本从哪里切。没有标签时，很容易在包含后续开发内容的分支上修热修，带入未完成改动。

候选阶段的沟通节奏

即使只有一个开发者，也要写候选日报或简短记录：今天进入哪个 rc，修了什么，哪些问题仍阻断，下一步验证什么。这样隔天回来不会忘记上下文。如果有测试者，沟通更要具体，不要只发“新包已上传”，而要说明测试重点。

测试者按重点测试，反馈质量会高很多。

候选分支和宣传素材同步

发售候选确定后，商店截图、预告片、公告截图应尽量来自候选构建或同等内容。不要用开发分支里未发布的新 UI 做宣传。候选分支治理不仅是代码，也包括对外展示内容的版本一致。

如果候选分支删掉了某个功能，宣传素材也要更新。否则页面承诺和发行包会错位。

热修分支从哪里切

发售后热修通常从发布标签或当前线上分支切，而不是从开发分支切。这样只带入必要修复，不带入未完成新内容。热修完成后，再把修复合回开发分支。这个顺序能减少“修一个线上 bug 顺便发布了半成品功能”的风险。

构建产物也要冻结

候选分支冻结代码还不够，构建脚本、资源导出配置、SteamPipe VDF、商店素材路径也要冻结。否则代码没变，打包方式变了，同样会引入风险。候选阶段如果必须改构建脚本，要像代码修复一样记录和回归。

发布事故很多来自流程文件而不是玩法代码，比如上传错 Depot、漏掉运行库、Demo 分支引用正式版目录。候选治理要覆盖这些文件。

最终发布包确认

切 default 前做最后确认：构建编号、Steam 分支、商店页发售时间、价格折扣、公告草稿、支持邮箱、回滚构建。把这些写成清单逐项勾，不要靠记忆。

清单完成后，把最终构建号写进发布记录。后续热修、复盘和玩家反馈都会依赖这个编号。