2026年6月17日，Epic Games 正式发布了 Lore——一个全新的开源版本控制系统，在 Hacker News 上迅速引爆讨论，以 920 分的高票登顶当日热榜。
背景：为什么需要又一个版本控制系统？
如果你觉得「版本控制」这个赛道已经被 Git 彻底统治了，那你可能不是游戏开发者。在游戏和影视行业，一个项目动辄包含数百 GB 的二进制资产——纹理贴图、3D 模型、音频文件、动画数据——传统 Git 在这些场景下表现堪称灾难。Git LFS 只是权宜之计，核心架构从未为二进制文件做过优化。
Epic Games 作为 Unreal Engine 和 Fortnite 的开发者，比任何人都清楚这个痛点。Lore 的前身是 Unreal Revision Control（URC），已经在 Fortnite 编辑器中承担版本控制职责。现在 Epic 将其彻底开源，以 MIT 许可证发布。
核心技术架构：Merkle 树 + 内容寻址
Lore 采用了与 Git 类似的内容寻址存储（Content-Addressed Storage），但设计理念有本质不同：
分块存储（Chunked Storage）：大型文件被拆分为可复用的数据块，每个块按哈希索引。这意味着一个 2GB 的纹理文件即使只修改了头部元数据，也只需要传输变更的块，而非整个文件重新存储。
不可变修订链（Immutable Revision Chain）：每次提交的哈希签名由修订状态 + 父提交哈希 + 数据哈希共同生成，形成密码学层面的防篡改链条。
按需水合（On-Demand Hydration）：工作区无需下载全部文件——只在真正访问文件时才拉取数据，大幅节省磁盘空间和带宽。
中心化服务架构：采用服务端缓存 + 持久化存储的分层架构，保证大规模团队的吞吐量。但与 Perforce 等传统中心化方案不同，日常操作（暂存、提交、分支、比较）完全离线执行，不需要网络往返。
与 Git 的关键区别
Lore 并非要「取代 Git」，而是在 Git 力不从心的领域提供替代方案。Git 的分布式模型适合文本代码协作，而 Lore 选择了中心化服务 + 离线操作能力的混合架构。在二进制合并方面，Lore 的策略是：文本文件走三方合并，二进制冲突则明确提示用户手动选择版本，推荐使用文件锁来避免并行编辑。
SDK 生态与多语言支持
Lore 提供了 C/C++、C#、Rust、Go、Python、JavaScript 六种语言的 SDK，覆盖了从游戏引擎到底层工具链的完整生态。CLI 工具提供一对一的功能映射，API 层面的全表面暴露意味着你可以将 Lore 嵌入任何自动化流水线。
社区反响
HN 社区讨论热烈（502 条评论）。多数开发者对 Epic 以 MIT 许可证开源的态度表示赞赏，也有声音质疑「又一个中心化 VCS」的必要性。支持者指出 Unreal Engine 生态对版本控制有独特需求——在 UEFN (Unreal Editor for Fortnite) 中，Lore 已被用于管理创作者岛屿的版本，并正在替代烹饪管线中的传统中间存储层，显著缩短了从发布变更到可游玩的时间。
当前状态与展望
Lore 目前处于 0.x 预稳定阶段，API 和协议可能还会演变。但 Epic 承诺：即使在这个阶段提交的数据，也将在未来的所有版本中保持可读。版本控制系统需要时间赢得信任——Epic 的策略是先让开发者和技术负责人探索、原型化、参与塑造方向。
📎 原文链接：lore.org
💬 HN 讨论：news.ycombinator.com