EpicGames/lore · 上手攻略

  • 仓库：EpicGames/lore
  • 链接：https://github.com/EpicGames/lore
  • 分类：engineering（trending）
  • 作者：Jay
  • 更新：2026-07-10

这是什么

Lore 是 Epic Games 开源的新一代版本控制系统，由 Epic Games 的工程师团队开发（Rust 语言，MIT 许可证）。它脱胎于 Epic 内部工具 Unreal Revision Control——曾是《Fortnite》 UEFN（Unreal Editor for Fortnite）创作工具的内置版本控制。2026 年 6 月，Epic 正式将其开源，面向所有有大规模二进制资产管理需求的团队。

Git 对代码文本文件极其高效，但对游戏、3D 资产、视频、AI 模型等大二进制文件力不从心——即便有 Git LFS 也是补丁式方案。Perforce 在游戏行业长期称霸，但它是闭源商业软件，学习曲线陡峭。

Lore 的目标是两全其美：Git 的开源和去中心化精神 + Perforce 对大文件的原生友好 + 现代云原生架构。

⚠️ 注意：Lore 当前为 pre-1.0（版本 0.x），接口、磁盘格式、API 均可能在版本间 breaking change，不建议直接用于生产核心代码库。但核心概念和架构已相当成熟。

解决什么问题

Git 的二进制困境

游戏项目通常包含： - 3D 模型（.uasset、.fbx、.obj）单文件可达数百 MB - 纹理贴图（.png、.dds）总量轻松破 GB - 音频文件、视频文件 - 预编译着色器、烘焙光照数据

Git 对这些文件每次全量存储，大团队协作时仓库体积爆炸，clone/pull 时间难以忍受。Git LFS 虽然解决了传输问题，但依然有仓库膨胀、免费额度过低等痛点。

Perforce 的使用门槛

Perforce（Helix Core）是游戏行业事实标准的 VCS，但： - 闭源，商业授权昂贵 - 命令行界面古老，学习曲线陡 - 对独立开发者和开源项目不友好

Lore 的答案

Lore 通过以下设计解决这些问题：

  1. 内容寻址存储（Content-Addressed Storage）：文件数据按内容哈希存储在 Merkle 树中，相同内容自动去重，无论在哪个分支、哪次提交。
  2. 碎片级去重（Fragment-Level Deduplication）：去重不仅在完整文件层面，还细化到文件片段——修改一个大文件的 1%，只新增 1% 的存储。
  3. 按需水合（Sparse On-Demand Hydration）：你不需要 clone 整个仓库，只需获取当前工作区需要的文件，节省磁盘和带宽。
  4. 集中式服务 + 本地缓存：服务器是权威记录节点（Single Source of Truth），但客户端有完整本地缓存，离线可继续工作，重连后同步。
  5. 免费分支（Free Branching）：分支只是轻量可变引用，创建和切换成本极低，底层数据不复制。

快速安装

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

--demo / $env:LORE_DEMO=1 参数会以本地演示模式启动，自动创建一个本地 Lore Server，不需要单独部署服务器，适合快速体验。

标准安装（非演示模式）

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash

# 或通过 cargo 安装（如果已有 Rust 环境）
cargo install lore

安装完成后验证：

lore --version

初始化一个本地仓库

# 初始化新仓库（演示模式下自动启动本地服务器）
lore init my-game-project

cd my-game-project

# 添加文件
echo "Hello, Lore!" > readme.txt
lore add readme.txt

# 提交
lore commit -m "Initial commit: add readme"

# 查看历史
lore log

核心用法

基本工作流

# 克隆远程仓库（需要先有 Lore Server）
lore clone https://your-lore-server/my-repo

# 查看状态
lore status

# 添加文件到暂存区
lore add .

# 提交（带消息）
lore commit -m "Update character model and textures"

# 推送到服务器
lore push

# 拉取最新更改
lore pull

# 查看提交历史
lore log

# 查看差异
lore diff HEAD~1

分支管理

# 创建新分支
lore branch feature/new-character

# 切换分支
lore checkout feature/new-character

# 或一步完成创建+切换
lore checkout -b feature/new-character

# 合并分支
lore merge feature/new-character

# 删除分支
lore branch -d feature/new-character

文件操作

# 查看某个文件的历史版本
lore cat -r <commit-hash> path/to/file

# 恢复文件到某个版本
lore restore -r <commit-hash> path/to/file

# 查看谁修改了某文件
lore blame path/to/file

服务器操作（需先部署 Lore Server）

# 连接远程服务器
export LORE_SERVER=https://lore.example.com

# 认证（首次）
lore auth login

# 创建新远程仓库
lore remote add origin https://lore.example.com/my-project

使用 SDK（以 Python 为例）

from lore import Repository, Client

# 连接本地演示服务器
client = Client("http://localhost:8080")

# 打开本地仓库
repo = Repository.open("./my-game-project")

# 读取当前提交历史
for commit in repo.log():
    print(f"{commit.hash[:8]} - {commit.message}")

# 获取某个文件的内容
content = repo.cat("path/to/file", revision="HEAD")
print(content)

# 检查文件完整性
print(repo.verify("path/to/file"))  # 返回 True/False

Lore 提供 C/C++、C#、Rust、Go、Python、JavaScript 六种语言 SDK，详见 Lore Python SDK、Lore JS SDK 等独立仓库。

典型适用场景

场景 说明
游戏开发（核心场景） 3D 资产、纹理、音频、视频等大二进制文件的版本管理
AI 模型版本管理 模型权重文件（通常数 GB）的高效存储与版本对比
多媒体/影视项目 视频剪辑、渲染素材的多人协作
数据科学团队 大数据集（预训练数据、特征工程中间结果）的版本控制
嵌入式固件 + 固件镜像 大型二进制固件文件的版本跟踪
独立游戏/工作室 不想买 Perforce 许可但需要 Perforce 级别大文件支持的团队

坑与注意

  1. Pre-1.0 风险：官方文档明确警告接口可能 breaking change，生产环境使用需承担风险。建议非核心项目试用，或等 1.0 版本。
  2. UEFN 尚未完全开源：Lore 是 UEFN 内置版本控制的开源版本，但 UEFN 构建使用专有压缩格式，open source 版本暂时无法与 UEFN 完整互通。Epic 正在将 UEFN 迁移到相同压缩格式。
  3. 服务器端需要自行部署：不像 Git 有 GitHub/GitLab 这种托管服务，Lore 需要自己部署 Lore Server，目前官方只提供二进制，暂无官方托管云服务。
  4. 生态系统尚在起步：Git 有 GitHub Actions、Git hooks 生态、各种 CI/CD 集成；Lore 的自动化生态几乎为零，短期内无法替代 Git 在 DevOps 流水线中的位置。
  5. Merkle 树结构学习成本：理解内容寻址存储的工作原理需要一定学习时间，团队推广有门槛。
  6. 演示模式限制：使用 --demo 启动的本地模式数据存在内存/临时目录，关闭后数据丢失——仅供体验，不适合实际开发。
  7. 与 Git 不兼容：Lore 不是 Git 的替代品，它是另一个 VCS 系统。你不能把 Git 仓库迁移到 Lore（没有官方迁移工具），也无法用 Git 客户端访问 Lore 仓库。

与同类对比

维度 Lore Git + Git LFS Perforce Plastic SCM
许可证 MIT（开源） Git: GPLv2 / LFS: MIT 商业闭源 商业，近年推免费计划
大文件处理 原生碎片级去重 Git LFS 需手动配置 原生优秀 原生支持
仓库体积增长 增量+去重，增长平缓 LFS 需付费配额 集中存储可控 分布式可控
学习曲线 中等（概念新） 低 高 中
分支模型 轻量免费分支 免费但仓库膨胀风险 分支重量级 分支较轻
CLI 体验 现代化直觉设计 成熟但古老 界面古老 较现代
生态系统 初期（Rust SDK 等） 极丰富（GitHub Actions 等） 成熟 一般
目标用户 大文件团队 通用/代码为主 游戏/影视大厂 游戏/独立开发者

一句话结论：Lore 在大文件版本控制上比 Git 强得多，但生态和成熟度远不如 Git——它是 Perforce 的开源挑战者，适合不想买 Perforce 但需要 Perforce 级别大文件管理的团队，但前提是你能接受 pre-1.0 的风险。

推荐结论

如果你正在开发游戏、AI 模型、影视内容，或任何涉及大量二进制资产的项目，Lore 值得关注。其碎片级去重和按需水合设计确实解决了 Git 的核心痛点，且 MIT 许可没有商业门槛。建议先在子项目/新项目中试点而非迁移核心仓库，并持续关注 1.0 发布动态。