6 月 17 日，Epic Games 在 GitHub 上公开了一个新仓库，MIT 许可，Rust 编写，名字叫 Lore。
项目主页上的定位非常清晰：下一代开源版本控制系统，专为项目和团队的极致扩展性而设计。特别适合那些把代码和大型二进制资产混在一起的场景，比如游戏、影视、娱乐内容。
HackerNews 当天冲到 1036 分，553 条评论，这个分数在 HN 历史上能排进前几十。一个版本控制系统的开源发布拿到这个热度，说明大家对现有方案的不满积压了太久。
帖子下一条高赞评论这样形容：在游戏行业，Git 是一个「方形的钉子」被锤进「圆形的洞里」。而 Lore 就是那个「圆形的钉子」。
Git LFS不够好，所以Epic自己造了一个
Git 在业内的地位自不必多说，其设计于2005年，Linus Torvalds 花了两周时间亲自给 Linux 内核写的。文本文件、分布式、每个人都是完整备份、离线也能干活，这些特性二十多年来对代码协作来说堪称完美。
但游戏开发的资产类型完全不同。贴图文件几百兆，3D 模型几百兆，渲染好的光照贴图几个 G。每个文件都是二进制，没法逐行 diff，没法自动合并，分块存储和去重是刚需。Git LFS 的思路是把大文件抽到远端，用指针文件替代。但这套方案只能说是在 2005 年的架构上打补丁，每个操作都要来回检查指针状态，离线环境下的稀疏检出有边界问题，跨团队的权限隔离没有原生支持。这些痛点每一个都算不上致命，但加在一起就是每天都在消耗团队的时间，带来额外的成本。
Epic 在 Phoronix 的报道里解释了他们的动机。没有一套现有系统是为游戏和娱乐项目的约束条件组合而设计的，包括任意内容类型、多维度扩展、多租户安全、完全开放的规范和许可。
事实确实如他们所说，游戏行业的版本控制长期靠 Perforce 顶着。Perforce 处理大文件比 Git 要好，但它是专有软件，协议不开放，去重能力有限，日常操作需要服务器往返。Git LFS 在开放性和社区生态上有优势，但处理二进制资产的效率远不如 Perforce。绝大部分游戏开发团队夹在两者中间，选哪个都不舒服。
Lore 就是冲着解决这个问题来的。
Merkle树加按需加载
Lore 的底层架构用了内容寻址存储加 Merkle 树加不可变修订链。Git 也是这套架构，但往下看，实现细节完全不同。
在文件存储方式上，Git 把文件存成 blob 对象，大文件用 Git LFS 抽出去。Lore 则是把文件拆成更小的 chunk，每个 chunk 独立寻址、独立去重。一个几百兆的贴图文件更新了其中 2MB 的内容，Git LFS 得下载整个文件再重新上传，Lore 只需要同步变动的 chunk。对于游戏开发这种频繁修改大文件的场景，这个差异会直接体现在等待时间上。
对于工作区的加载方式，Git 的稀疏检出是后来加上去的功能，有很多边界情况没处理好。Lore 的按需填充是天生就设计好的核心能力，工作区只在需要的时候才下载文件数据，你不用提前拉取整个仓库。打开项目，只加载你当前需要的部分。这对于动辄几十个 G 的游戏项目来说，体验差异非常明显。
分支的管理方面，Git 的分支就是指针，轻量、快速，这是 Git 做得最好的部分之一。Lore 做了同样的事，分支是轻量级可变引用，创建和切换的开销都很低，不会因为底层数据重复而变慢。
还有一个很容易被忽略的细节，Lore 为 C/C++、C#、Rust、Go、Python、JavaScript 六种语言提供了完整的 SDK。这组 SDK 指向的是一个特定场景 —— DCC 工具的插件开发。一个 3D 美术师不需要理解 Merkle 树和内容寻址，他只需要在他常用的建模软件里点一下「保存到 Lore」，工具通过 SDK 去完成提交。这套 API 层的设计说明 Lore 并不只是给程序员用的。
集中式是倒退吗？
Lore 的架构选择可能会让熟悉 Git 的开发者感到意外，因为它是集中式的，服务器是真实的记录来源，客户端按需拉取。
这个选择在对等协作的软件工程领域是倒退，但在游戏开发领域是务实。
原因很简单，游戏项目里一个几百兆的贴图文件在团队里流转，每个人都需要能立刻拿到最新版本，但不需要把整个仓库的所有历史都塞进本地硬盘。集中式在这个场景下反而是对资产特性有清醒认知后的设计决定。服务器做冲突解析和权限控制，客户端做按需加载和本地操作。日常的暂存、提交、分支切换、差异对比都不需要走网络往返。
Lore 的官方文档里详细解释了这套思路。Git 的内容寻址修订图非常好，但它把二进制文件当作二等公民，大文件需要外挂 LFS 而不是原生分块存储。集中式系统处理大文件很擅长，但它们的日常操作依赖服务器往返，使用专有的有线协议，去重能力有限。Lore 的做法是把两者各自最好的部分结合起来。
Lore不会取代Git，但游戏行业的VCS格局会变
当然我们并不是说 Lore 和 Git 放在一起比谁更强，Git 解决的是代码的分布式协作，Lore 解决的是大型二进制资产的集中式管理。它们服务的场景不同，用户群体不同，构建的生态也不同。
Git 的生态是过去二十几年的积累，GitHub、Gitee、GitLab、Bitbucket、CI/CD 管线、Code Review 流程，全都围绕 Git 构建。一个开发者学会 Git 之后几乎可以接入整个开源世界，这个生态护城河极深。
Lore 面对的生态挑战更大。Perforce 在游戏行业扎根了二十多年，美术师和 TA 的工作流围绕它搭建。3D 建模软件的版本控制插件、渲染农场的集成、构建管线的适配，全都绑定在现有系统上。要让一个工作室把整个管线迁到 Lore 上，光靠代码层面的优势或许还不够。需要 Blender 插件、Maya 插件、Houdini 插件、游戏引擎的深度集成都到位。
Epic 把六套 SDK 先写出来，就是在为这些工作做铺垫。据悉 Lore 目前已经是 UEFN （堡垒之夜编辑器）的内置版本控制系统。开源版本现在还不兼容 UEFN 使用的专有压缩格式，但 Epic 表示正在推动迁移到统一的开放压缩格式。一旦内部产品完成迁移，Lore 就有了一个大规模的生产环境验证案例，这对说服外部市场接受这个新工具很有帮助。
至于 HN 排名第一的那条评论：在游戏行业，Git 是方形的钉子被锤进圆形的洞里，Lore 是那个圆形的钉子。
Lore 不会取代 Git，就像 Git 没有取代 SVN。但 Lore 的出现还是说明了一些问题，当你的场景跟已有工具的设计假设不同时，值得从头思考整个系统应该怎么搭。Epic 花了三到五年（从 UEFN 产品线推算），用 Rust 写了 17 个 crate，把 Merkle 树、分块存储、按需加载、六语言 SDK 整合成一个完整的系统。
这可能谈不上是什么夸张的技术突破，但绝对是一线游戏开发者在工程上的仔细取舍。
参考来源
Lore官网-lore.org
Lore GitHub仓库-https://github.com/EpicGames/lore
Phoronix报道-https://www.phoronix.com/news/Epic-Games-Lore-VCS
Heck News 原帖-https://news.ycombinator.com/item?id=48571081
