TA 工具版本控制

先把题目说成人话

一位美术从旧共享盘打开批处理工具，却拿它读取新版配置。窗口没有报错，产物也能生成，只是通道含义已经悄悄错了。若团队为了避免误点而删掉所有旧工具，正在维护旧项目的人又无法重现当时环境。现实要解决的不是“永远追最新版”，而是让每个项目拿到一套明确兼容、能够复现和退回的工具组合。

保存文本修改历史的系统叫版本库（Git），把大二进制内容另存、只在版本库里留指针的扩展叫大文件存储（Git LFS）。配置字段长什么样、各自代表什么叫数据格式契约（schema）；项目锁住精确工具与依赖组合的清单叫锁定文件（lockfile）。代码版本、配置格式和宿主版本是三条不同的轴，不能只看一个“最新版”标签。

这是虚构教学故事，不是个人项目经历。

场景：先让问题变得看得见

假设材质批处理工具从 v1 升到 v2，配置字段 roughnessSuffix 改成了通用的 channelRules。一位美术从旧共享盘启动 v1，用新配置处理资产，输出内容悄悄错误。团队把工具版本、配置版本、宿主版本和一份可回滚样本记录为发布基线。

（右脑）画面：桌上摆着四只必须同时咬合的齿轮：第一只决定工具会做什么，第二只决定配置单长什么样，第三只代表承载工具的制作软件或引擎，第四只把当前项目固定在一组已经验证的组合上。仓库保留每只齿轮的历史，发布时把一套相配齿轮封进不再原地覆盖的盒子。启动器先比对齿距，再决定直接运行、先复制并迁移配置，还是带人退回上一盒；它不会因为看见“更新”两字就强装一个不配套的轮子。

（左脑）对表：本题对象是脚本、二进制样本、配置 schema、宿主版本、发布包和项目锁定版本。v1 读取新配置并静默产出错误是观察事实；“删掉所有旧版就安全”是假设。证据来自兼容矩阵、旧/新配置样本、迁移 dry-run、发布校验和回滚复现。文件大小以字节计，但是否进 LFS 还取决于可否重建、是否需要逐版本保存；语义版本、schema 版本和宿主版本是三条不同坐标轴。齿轮与封箱类比帮助看见组合与回退，不等于证明“最新版”天然兼容当前项目。

小明：先形成一个完整猜测

小明准备删除共享盘上的所有旧版，只留最新版。这样能阻止误点，却也让正在旧分支修 Bug 的项目失去可复现环境。这个反例说明：旧版可以不再允许进入不兼容项目，但仍应被保留用于回滚和历史分支。

小红：把猜测放回现实检查

小红先不改资产，让启动器读取工具声明的 toolVersion、configSchema、宿主版本范围和项目锁定版本。结果表明 v1 能读取旧 schema，不能安全读取新 schema；阻断理由因而从“版本旧”变成了“数据契约不兼容”。

她也把文件分类：.cs/.py/.ms、JSON/YAML 配置和迁移脚本由普通 Git 管；PSD、二进制 DCC 文件、测试模型等确实需要版本且体积大的文件才进入 Git LFS；可重建缓存、日志和导出中间物不应因为“大”就塞进 LFS。

我：用检查结果修正模型

我把工具发布成不可变版本（例如 UPM 包或带版本目录的 DCC 包），项目通过 manifest/lockfile 指定版本。启动时兼容就运行；存在迁移器时先生成 dry-run 报告和备份，再升级 schema；完全不兼容则明确阻断，并提供“打开匹配旧项目的工具”或“回到上一稳定版”两个入口。禁止从共享盘直接覆盖同一个 latest 文件夹。

每个 release 附变更日志、依赖范围、迁移步骤、校验样本和回滚版本；CI 用旧配置、新配置各跑一次。最终还要在目标 Unity/DCC 版本和真实项目副本中验证，因为 Git 提交成功不代表宿主 API 与资产 schema 兼容。

原题问的是“你如何管理、是否使用 Git LFS”。是否真的用过、管理过多大仓库、处理过什么迁移或回滚，必须由你本人的仓库记录、提交和发布日志证明；这套教学方案不能冒充使用经历。若只理解原理而没有实际用过，就应如实说明。

（右脑）画面修正：小明想删掉全部旧版，虽能阻止误点，却让旧分支失去可复现环境；小红让启动器读取 toolVersion、configSchema、宿主范围与项目锁定版本，确认真正的冲突是 v1 无法安全读取新 schema，而不是它单纯“太旧”。模型由此从“新版本替掉旧版本”改成“版本并存、项目锁定、按数据与宿主契约放行”：旧工具仍可服务匹配的旧项目，但不能越过 schema 或宿主边界处理新数据。

（左脑）严格对表：文本代码、配置和迁移脚本进普通 Git；确需版本化且不适合 diff 的大型二进制进 LFS，需多人排他编辑的 DCC 文件还要按团队流程评估 LFS lock；缓存、日志和可重建导出物排除。每个不可变 release 声明 toolVersion、configSchema、宿主/依赖范围、校验样本和上一稳定版，项目以 manifest/lockfile 固定它。启动时若直接兼容则运行；若存在迁移器，先备份并输出 dry-run，验证后生成新 schema；若不兼容则阻断并提供匹配旧工具或回滚入口。CI 必须用旧/新配置和目标 Unity/DCC 版本跑样本；真实 Git LFS 使用经验只能由仓库记录说明。

老师解惑

• Git LFS：Git 保存指针，LFS 存放大二进制内容；它不是所有大文件的垃圾桶，也不能替代发布管理。
• 语义版本与 schema 版本：工具代码版本和数据格式版本是两条轴；代码小改也可能需要数据迁移。
• 不可变发布：已发布版本不原地覆盖，项目才能重现和回退。
• 兼容阻断：依据明确的宿主、依赖和 schema 范围阻断，而不是简单判断“是不是最新版”。

工具分工

• Git / Git LFS：分别管理文本历史和确需版本化的大二进制文件。
• UPM/启动器/manifest：安装并锁定工具与依赖版本。
• 迁移器：读取旧 schema，预览变更，备份后产生新 schema。
• CI 兼容矩阵：在声明支持的 Unity/DCC 与配置版本上运行样本。

记忆钩子

项目锁住能复现的版本；旧工具因契约不兼容而停，不因“不是最新”而消失。