上架素材的版本管理与备份

直接结论

listing 素材需要版本管理，原因和代码一样：商店后台只保留在线版本，所以一旦出事——提审被拒、某次编辑后转化下滑、某个 locale 被误覆盖——第一个问题永远是「到底改了什么、之前是什么样」，而后台回答不了。可用的体系需要四个属性：每类素材有唯一权威位置（不是「共享盘里最新的那个文件」）；每次提审时对完整素材包做快照；一份记录谁改了什么、为什么改的变更日志；以及一条测试过的、能还原任意历史版本的恢复路径。这些都不需要重型工具——需要的是一个决定：listing 素材包是一个有版本的工件，不是一堆最新草稿。

该管版本的东西

推荐流程

1. 给每类素材声明唯一权威位置

每个素材只有一个权威所在地，其余全是副本。当一个副标题同时存在两个「当前版本」——文档里一个、后台里一个——体系就已经无声地失败了。

2. 每次提审做完整包快照

每次提交前，把提交内容原样存档：所有 locale、所有字段、所有图片文件，打上日期和版本标签。这个工件负责回答被拒时的所有问题、支撑真正的回滚。快照存放在持久、且和工作文件分开的地方。

3. 修改的当下就写日志，带上原因

一条变更日志在修改当下写只要三十秒，三周之后就再也补不回来。最少字段：日期、素材、谁、改了什么、为什么。那个「为什么」是让日志从记账变成诊断材料的关键。

4. 源文件和导出品配对管理

拍平的截图 PNG 是你上架的东西，分层源文件是你维护的东西。两者要一起管版本——一个和上架导出品脱节的源文件，是给下一个编辑者埋的雷。

5. 在需要之前测一次恢复路径

刻意地做一次：拿上季度的快照，完整走一遍还原某个 locale 素材包的流程。如果还原依赖一个已离职的人或一个没人有授权的工具，你有的只是备份，不是可恢复性。

6. 按发布节奏安排例行备份

提审时的快照覆盖大部分需求；定期导出后台状态（每季度、或批量修改之前）覆盖其余——包括那些绕过流程、直接在后台改的变更，这种事哪个团队都有。

常见失败模式

把共享盘当版本管理

叫 final、final2、final-确认版-新 的文件夹不是版本，是一场所有人迟早都会输的记忆测验。唯一权威位置加带日期的快照，才能取代猜谜。

有快照没有为什么

只存文件不存原因的团队，什么都能还原、什么都解释不了。指标动了的时候，日志里那列「为什么」是诊断和考古的分界线。

绕开体系的后台直改

发布周里「在后台顺手改一下」的操作永远进不了日志，你的记录和线上的下一次 diff 就是错的。规则：后台改动当天补录，没有例外——更好的做法是让它们走和其他修改一样的管道。

只给主语言管版本

英文包有版本管理，其他 locale 只存在于「线上是什么样就是什么样」。而 locale 事故——误覆盖、素材过期、传错市场——恰恰是恢复请求的主要来源。

版本管理清单

1. 每类素材、所有 locale 都声明了唯一权威位置。
2. 每次提审有完整包快照，打标签、存放持久。
3. 变更日志包含日期、素材、负责人、改动、原因。
4. 分层源文件和上架导出品一起管理。
5. 用真实快照实测过一次恢复路径。
6. 定期导出后台状态，兜住体系外的直改。

执行原则

如果你不能在十分钟内拿出任何一个 locale 上个月的完整 listing 包，你没有版本管理——你有的是乐观。

为什么这件事适合放进 App Store Helper

App Store Helper 把 listing 素材包当作一等的版本化对象：元数据、截图素材和语言变体住在同一个项目里，带编辑历史、review checkpoint 和成文的修改原因。「我们提交的包里是什么、为什么」不再是一场重建工程。