Epic Games 发布下一代版本控制系统 Lore：被 HN 干到 1000+ 分的“游戏版 Git“

⚠️ **免责声明：**本工具依赖境外公开数据源，部分平台在中国大陆需合规网络环境。

每日开源 · 第 094 期

Epic Games 发布下一代版本控制系统 Lore：被 HN 干到 1000+ 分的"游戏版 Git"

2026.07.14 · 早间篇 · 阅读约 8 分钟

7,600+

GitHub Stars

335+

Forks

Rust

核心语言

MIT

开源协议

项目速览

**项目：**EpicGames / lore

**定位：**下一代开源版本控制系统，专为代码+大型二进制资产的混合项目设计

**语言：**Rust（核心库/CLI/Server），SDK 覆盖 JS/Python/C#/Go/C

**许可：**MIT，完全开源，无任何付费墙

**状态：**v0.8.4（Pre-1.0），已在 UEFN 生产环境中验证

**GitHub：**github.com/EpicGames/lore

2026 年 6 月 17 日，Epic Games 在年度虚幻引擎大会上扔出一枚重磅炸弹：一个他们自己从零写的版本控制系统 。项目当天冲上 Hacker News 首页，斩获 1036 分、553 条评论，在 HN 历史排行榜上都能挤进前几十。仅仅一个月后，Lore 已经收获了超过 7,600 个 GitHub Stars。

这不是又一个 Git 封装------Lore 从底层存储模型到网络协议都是全新设计的，旨在解决一个 Git 诞生 21 年来从未真正解决的问题：当一个项目同时包含几 KB 的源代码和几百 GB 的 3D 模型/贴图/音频时，版本控制应该怎么设计？

◆ ◆ ◆

它能解决什么问题？

如果你在游戏、影视、VR/AR 行业做过开发，以下场景一定不陌生：

🔴 场景一：新人入职要等半天

克隆一个 500GB 的游戏项目仓库，光下载就要几小时。实际上你只需要改几个脚本和几张贴图，但 Git 不管你这么多------整个历史都得拉下来。

🔴 场景二：改个贴图，仓库胖一圈

美术修改了一个 200MB 的 PSD 源文件，只动了其中一个图层。Git LFS 存了两个完整副本，仓库体积爆炸。Perforce 倒是能增量存，但必须实时连着服务器------断网就没法干活。

🔴 场景三：工具链分裂

程序员用 Git，美术用 Perforce，策划用 SVN。不同团队的版本控制互不相通，管理成本极高。有没有一个系统能同时满足所有人？

**Lore 的设计目标：**集中式架构保证一致性和访问控制，内容寻址存储实现 Git 级别的去重和完整性，分块+按需加载让 TB 级仓库也能在笔记本电脑上工作。

◆ ◆ ◆

核心亮点：Lore 凭什么与众不同？

📚 1. 内容寻址存储 + Merkle 树

Lore 使用 BLAKE3 哈希（256位）作为内容地址。每个数据片段（fragment）的地址由字节内容的哈希派生，而非人为分配。这和 Git 的 blob 机制思路类似，但实现粒度截然不同。

文件目录组织为 Merkle 树：根哈希唯一标识整个仓库状态。两个仅差一个文件的修订版，共享所有未修改的节点块 （相同哈希 = 同一存储条目，零额外拷贝）。提交新修订版时，存储成本与修改的块数量成正比，而非树的总大小。

每个修订版状态是一个 320 字节的 blob，包含根树哈希、父修订哈希、元数据哈希等。小到可以一次往返获取并验证，不需要额外拉取。

📚 2. 分块存储：改 1MB 只传 1MB

这是 Lore 最核心的技术差异点之一。对于大文件，Lore 提供两种分块策略：

**FastCDC（内容定义分块）：**基于滚动哈希，边界由内容决定而非偏移量。文件开头插入字节后，后续边界同步移动，小编辑只产生改动附近的新块。平均 64KB/块，下限 32KB，上限 256KB。大文件稀疏写入场景的利器。

**固定大小分块：**边界仅由偏移量决定，相同内容始终产生相同块------保证规范地址（canonical address）。适合需要确定性寻址的场景。

更精妙的是递归分块 ：大文件产生大量块，fragment 引用列表本身可能超过 256KB 阈值，此时列表被递归分片，形成fragment 列表树。每层独立寻址、去重、惰性获取。对上层 API 完全透明。

压缩和寻址解耦：地址 = 未压缩内容的哈希，更换压缩算法不改变地址。当前使用 Zstd，编解码器列表开放。

📚 3. 按需加载：TB 级仓库也能在笔记本上工作

这是 Lore 设计理念中最重要的一个词：稀疏为默认模式。

**视图文件（.lore/view）：**声明你希望磁盘上物化的路径。视图外的路径在同步/切换/恢复时不被物化------文件在仓库树中存在，但不写入工作目录。**惰性获取：**从多 GB 文件读取 4MB 字节范围 → 仅获取重叠该范围的 fragment。树遍历时走到一个文件的一条路径 → 不需要获取整个树的所有节点块。**共享存储：**同一台机器上的多个工作副本可以共享一个 fragment 存储。内容去重在 fragment 级别，相似文件也能共享公共部分。**LRU 淘汰：**按用户配置的磁盘预算自动淘汰旧 fragment。

想象一个 500GB 的游戏项目：改几个脚本和几张贴图，传统 Git 工作流必须下载 500GB。在 Lore 中，你可能只需要下载几百 MB 的实际数据。

**设计哲学：**物化成本跟踪工作子集，获取成本跟踪尚未见过的内容，存储成本跟踪实际触及的内容。对树的一小部分操作快速运行，无论树的其余部分多大。

📚 4. 不可变修订链：密码学级别的历史完整性

每个修订版状态哈希覆盖完整的 320 字节，包括父修订状态签名。修改父修订版的任何字节 → 父哈希改变 → 子修订记录的父签名仍指向旧哈希 → 链可验证断裂。

没有 force-push，没有历史重写。如果必须删除已推送到仓库的内容（如密钥泄露），使用 file obliterate 命令------它会擦除文件内容，后续尝试获取时返回清晰错误，而非暗中篡改历史。

📚 5. 日常操作零网络往返

这是 Lore 相比 Perforce 最显著的优势，也是它从 Git 借鉴的核心设计：暂存、提交、分支、diff 全部在本地完成，无需服务器往返。

离线：创建分支、提交修订、比较差异------全部可用在线：push 将本地修订推送到服务器，sync 拉取远程变更所有状态转换通过 **CAS（compare-and-swap）**原子操作完成------这是架构中唯一真正的串行化点

中断的 push 不会产生半成品：fragment 已写入不可变存储但没有指针指向它们，分支仍显示在之前的最新修订。

📚 6. 分区隔离：知道哈希 ≠ 能拿到数据

Lore 引入了**"分区"（partition）**概念：16 字节不透明标识符作为内容作用域，绑定到分区的会话无法查询其他分区的 fragment。底层存储可以跨分区去重相同字节，但 API 层面不泄露。

这对于大型工作室非常关键：外部承包商只需访问指定目录，有版权的第三方资产与内部代码天然隔离，复制/克隆不能绕过权限。

📚 7. 一等公民的 API 设计

CLI 不是特权通道。所有交互通过统一 API 接口------任何基于相同接口构建的工具都能实现与 CLI 完全相同的功能。官方 SDK 覆盖 C/C++、Rust、C#、Go、Python、JavaScript 六种语言。

这意味着：IDE 插件、DCC 工具集成、自定义 GUI 客户端、CI/CD 管线------都可以基于同一套 API 构建。

◆ ◆ ◆

架构深度拆解

Lore 采用集中式、内容寻址架构。核心分成两大子系统：

存储子系统（lore-storage）

不可变存储（内容寻址 fragment）+ 可变键值存储（分支指针、元数据）。存储子系统可独立使用------作为构建缓存、资产管线、备份目标、多租户制品服务，无需触及版本控制层。

版本控制子系统（lore-revision）

Merkle 树管理、分支、合并、冲突解决。它是存储 API 的消费者之一，而非拥有特权的层。

传输层

基于 QUIC 协议（vendored quinn-proto），支持 BBR 和 Cubic 拥塞控制。自定义 CWND 种子注入以减少延迟。gRPC + Protocol Buffers 定义服务接口。支持 mTLS 服务器间通信。

存储后端

参考实现使用 AWS S3（不可变存储）+ DynamoDB（可变键值存储），但存储和传输层位于文档化接口之后，第三方后端可自由实现。

节点块设计：零拷贝反序列化

每个节点块固定 49,280 字节（512 个节点 × 96 字节 + 128 字节块头），恰好一个 fragment。所有字段宽度都为实现零拷贝反序列化而设定------可从磁盘 mmap 到内存直接使用，无需解析或拷贝。

◆ ◆ ◆

Lore vs Git vs Perforce：核心差异

**📂 文件存储：**Git 把大文件交给 LFS（外部插件），存完整 blob；Perforce 二进制管理出色但闭源；Lore 对文本和二进制一视同仁，都走分块+内容寻址+去重------原生支持，非附加功能。

**🌐 工作模式：**Git 分布式，本地有完整历史，但大仓库克隆慢；Perforce 集中式，日常操作需连服务器；Lore 集中式+本地操作------服务器管权限和持久化，日常编辑全离线。

**🔒 暂存区：**Git 暂存区固定内容（staging 时拍快照）；Lore 暂存区固定路径（commit 时取当前文件内容）------更直观，不会出现"工作目录、暂存区、提交历史三个版本各不相同"的困惑。

**📜 历史修改：**Git 支持 force-push/amend/rebase 重写历史；Lore 历史不可变，误操作用 file obliterate 声明式删除而非暗中篡改。

**🔒 访问控制：**Git 仓库级别粗粒度；Perforce 有灵活的保护表；Lore 分区级别------内容哈希 + 分区 ID 双重控制，知道哈希不等于能访问。

🔗 子仓库：Git submodule 管理复杂、版本锁定困难；Lore 的 link 和 layer 支持克隆仓库的选定子目录，且每个链接仓库有独立分区和访问控制。

**重要结论：**Lore 不会取代 Git。Git 解决的是代码的分布式协作问题，Lore 解决的是大型二进制资产的集中式管理问题。两者的服务场景、用户群体和生态不同。但对于游戏/影视行业，Lore 可能是继 Perforce 之后最值得关注的版本控制方案。

◆ ◆ ◆

上手指南：10 分钟体验核心循环

Lore 提供单行命令安装 + 一键启动本地服务器（Demo 模式），无需 Rust 环境、无需 Docker、零配置。

1****安装并启动本地服务器

安装脚本自动下载 CLI 和 Server 二进制、添加到 PATH、启动本地服务器（监听 41337/41339 端口）。

bash 复制代码

# macOS / Linux curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash -s -- --demo  # Windows PowerShell $env:LORE_DEMO=1; irm https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.ps1 | iex

2****验证服务器健康 + 创建仓库

bash 复制代码

# 验证服务器 curl -i http://127.0.0.1:41339/health_check  # 创建项目并初始化仓库 mkdir ~/my-project && cd ~/my-project lore repository create lore://127.0.0.1:41337/my-project

3****添加文件、暂存、提交

暂存统一处理添加、编辑、删除。移动/重命名使用专用子命令。提交完全本地操作，零网络往返。

bash 复制代码

# 创建文件 echo "Hello, Lore" > hello.txt  # 暂存（等同于 git add） lore stage hello.txt  # 提交（完全离线） lore commit "Initial revision"  # 推送到服务器 lore push

4****分支与合并

bash 复制代码

# 创建分支 lore branch create my-feature  # 在分支上修改、暂存、提交 echo "New feature" > feature.txt lore stage feature.txt lore commit "Add feature"  # 切回 main 并合并 lore branch switch main lore branch merge my-feature --message "Merge feature"  # 推送到远程 lore push

5****克隆第二个工作树（共享存储）

共享存储让多个工作树共享同一份磁盘副本，fragment 级别去重，相似文件也能共享公共部分。

bash 复制代码

# 创建共享存储 cd ~ lore shared-store create lore://127.0.0.1:41337  # 克隆到新目录（使用共享存储） lore clone lore://127.0.0.1:41337/my-project my-project-b --use-shared-store  # 同步远程变更 cd ~/my-project-b lore sync

📌 命令速查

bash 复制代码

lore repository create <url>          # 创建仓库 lore stage <file>                     # 暂存文件 lore stage move <from> <to>           # 暂存移动/重命名 lore status --scan                     # 查看状态 lore commit "message"                  # 提交修订 lore push                              # 推送到服务器 lore sync                              # 同步远程变更 lore branch create <name>             # 创建分支 lore branch switch <name>             # 切换分支 lore branch merge <source> --msg "M"  # 合并分支 lore branch merge resolve              # 解决合并冲突 lore branch merge abort                # 放弃合并 lore clone <url> <dir> --use-shared-store  # 克隆仓库 lore file obliterate <path>           # 声明式删除文件

◆ ◆ ◆

路线图展望

Lore 目前仍是 Pre-1.0 阶段，但路线图已经规划得非常清晰：

📅 2026 年 --- 夯实基础

**UEFN 兼容：将 UEFN 项目从 Oodle 压缩迁移到 Zstandard，让开源工具链能直接连接 UEFN 的 Lore 服务器 VS Code 插件：图形化界面，日常操作一键完成 可扩展文件锁定：百万文件+千级并发用户下的锁定执行 虚拟文件系统（VFS）：TB 级项目克隆后秒级可用，文件按需加载，从不重复存储Links & Layers：**多仓库组合为单一工作树，每个链接有独立访问控制

📅 2027 年 --- 扩展与协作

**桌面客户端开源：当前已提供二进制下载（Windows/macOS/Linux），计划全部开源 Unreal Editor 插件：在 UE 编辑器内原生管理版本，美术无需碰命令行 Web 客户端 + Code Review：浏览器内完成代码审查和仓库管理，完全开源自托管边缘实例 + 高级服务器拓扑：**跨地域团队复制优化，全球就近访问

◆ ◆ ◆

今日总结

Lore 是一个深思熟虑的工程决策，而非简单的 Git 替代品。它从 Game/Entertainment 行业的实际需求出发，系统性地重新设计了版本控制的核心抽象：内容寻址存储、分块去重、按需加载、分区隔离------这些特性拼在一起，构成了一套**"代码+海量二进制资产"场景下最优解**的版本控制系统。

💡 几点判断：

Lore 的设计处处体现工程权衡的精妙------集中式不是倒退，是对游戏行业的务实回应
从存储子系统到版本控制层的清晰分层，意味着 Lore 的存储层本身就是一个可独立使用的通用基础设施
MIT 协议 + 六语言 SDK + 公共路线图 = 面向生态的长期投入，不是一次性开源作秀
Pre-1.0 格式可能变，但内容已承诺永久可读------可以放心试用

它不会取代 Git，但它可能成为游戏/影视/VR 行业版本控制的事实标准。就像游戏引擎有 Unreal 和 Unity，版本控制未来也许会有 Git 和 Lore 各自擅长的领域。

🚀 今天的项目对你有启发吗？

如果觉得有用，欢迎转发给需要的朋友。也欢迎留言说说你在管理大文件版本时踩过的坑。

🔗 GitHub 仓库 📖 官方文档

每日开源 · 每天介绍一个值得深读的开源项目

第 094 期 · 2026.07.14 · 早间篇

素材来源：GitHub README、Lore 官方文档（系统设计/FAQ/快速入门/路线图）、CSDN EveningTalk、imcn.me、asawicki.info、ghtrends.dev