3D 模型的版本管理：为什么 git 管不动二进制文件

团队第一次用 git 管理 3D 模型，几乎都会踩同一个坑：仓库体积半年内涨到几十 G，clone 一次要半小时。原因是 git 对二进制文件按整份存储，改一个顶点也会存一份完整的旧版本。 解决方案有几个方向，我的实践是这样的。 方向一：Git LFS。把模型、贴图这类二进制交给 LFS 管理，仓库里只存指针。这是最常用的方案，迁移成本低，主流的代码托管平台都支持。缺点是配额通常要额外付费，而且团队新人要先装好 LFS 才能正常 clone，忘了装会拿到指针文件而不是真模型。 方向二：资源和代码分离。模型资源放在独立的资源仓库，代码仓库只存引用和版本号。这样代码仓库保持轻量，资源仓库可以按需拉取。这个方案适合资源量特别大的项目。 方向三：程序化生成优先。能用代码生成的资源就不存二进制，把生成脚本和参数入库。这是最优雅的解法，diff 有意义、体积小、可复现。适用面有限，但对地形、植被、场景布局这类资源非常有效。 不管用哪个方案，有两条规约必须立起来： 一，模型导出前必须做清理，删掉历史图层、未使用的材质、隐藏的物体。很多模型的体积有一半是这些看不见的东西。 二，资源提交必须走自动化校验，检查命名规范、文件体积上限、贴图分辨率上限。人肉检查一定会漏。 关于 agent 的使用：校验脚本、LFS 配置、CI 集成这些基础设施，让 Claude Code 一次写全并提交 PR 是很顺的。而模型本身的内容审阅，比如新旧版本在视觉上的差异，交给 MiMo Desktop 的预览来看，比对着文件大小猜要靠谱。 最后：版本管理的目标不是"能回退"，是"回退到哪一版是有意义的"。命名规范和提交信息比工具更重要。