스크립트
00:00:00Epic Games 构建了自己的版本控制系统，仅仅是因为他们受够了 Git。
00:00:05他们用 Rust 编写了它，然后将其开源发布。它叫 Lore。所以没错，
00:00:10《堡垒之夜》背后的公司打造了一个 Git 的替代品。但 Git 依然非常棒，
00:00:15显而易见。不过 Git 是为代码而生的。主要是文本文件，很多小文件，
00:00:21通常每次只改动几行。游戏开发基本正好相反。那么
00:00:26Lore 与 Git 相比如何，我们又该如何使用它呢？让我们一探究竟。
00:00:35在这一点上，我们有海量的纹理、音频文件、视频、3D 模型，
00:00:41以及各种各样的二进制资产，每个文件可能都有几百兆甚至几 GB 大。而且
00:00:47一旦这些文件开始变动，情况就会变得非常混乱。仓库变大，克隆变慢，
00:00:53历史记录变得臃肿。最终有人会说，好吧，也许我们该用 Git LFS。Git LFS 有帮助，
00:01:01但它也感觉像是在一个从未为这种数据设计的系统上打补丁。
00:01:06此外还有配额、带宽限制，以及历史记录中残留的老旧资产。所以
00:01:12很多工作室使用 Perforce。平心而论，Perforce 确实好用。那么多游戏
00:01:18工作室使用它是有原因的，但它很贵。它可能很复杂。而且一旦你的系统规模扩大，
00:01:24通常总得有人专门负责维持它的正常运转。这就是 Lore
00:01:29设计初衷要解决的问题。如果你喜欢通过编码工具来加速工作流，请务必订阅。
00:01:35我们会不断发布视频。好的。现在，不仅仅是谈论 Lore，
00:01:39它很酷。让我把它运行起来。我来演示一下它是如何工作的。演示从一个安装
00:01:44命令和一个演示标志开始，我们马上运行一下。就是这样。几秒钟后，
00:01:51我就有了一个在本地运行的 Lore 服务器。没有云账号，没有密钥，没有证书设置。它正运行在
00:01:57这些端口上。为了证明它真的活着，我可以直接访问这里的健康检查端点。
00:02:03我将在终端执行这个操作。好了，它活着，它在运行。
00:02:08不需要我手动连接任何后台服务。不需要生成验证令牌。没有
00:02:14设置向导。它直接启动。现在，让我创建一个仓库。所以我要创建一个文件夹，
00:02:22对吧？我们要创建这个仓库。现在我要创建一个大型二进制文件
00:02:27并提交它，对吧？这只是一个虚拟文件。但让我们创建一个更大的文件。我正在运行
00:02:32DD 来进行数据复制。现在，Lore 不会把那个 100 兆的文件当作一个巨大的对象，
00:02:40而是将其分解成更小的块。这些块会被哈希化，用 Zstandard 压缩，并存储在一个
00:02:47基于内容的 Merkle 树中。如果文件大部分保持不变，Lore 不需要保存整个文件的另一个完整副本。
00:02:52它可以重用已有的块，仅存储发生变化的部分。
00:02:58这对于大型二进制资产来说是非常好的方案。在提交完成后，你可以看到
00:03:04磁盘上创建的本地状态。这里现在有一个 Lore 目录，包含配置和
00:03:10元数据。好了，现在我们有了它，让我们创建一个分支。好的，我可以运行 Lore branch create
00:03:17命名分支。它的工作方式和 Git 非常像。所以让我们切换到它。让我们确实做一个小的
00:03:24改动。我会快速创建一个文本文件并提交到这个分支。所以我们修改，然后可以暂存，
00:03:31然后我们提交它，对吧？整个流程大致和 Git 一样。现在我要切换
00:03:37回来。这基本上是瞬间完成的。另一个重要的事情是，所有这些都不需要
00:03:44访问服务器。暂存、提交、分支、切换、差异比对，所有这些都是在本地完成的。所以
00:03:50即使 Lore 有一个中央服务器，你日常工作依然感觉很快，而且你可以保持
00:03:56离线工作。它让一切都感觉非常轻量。现在问题来了，好的，
00:04:02所有数据都去了哪里？在这个演示中，一切都是临时的。所以当我停止服务器时，
00:04:08数据就会消失。这是因为我只使用了演示模式。在实际设置中，你会用
00:04:15配置文件和持久化存储来运行 Lore 服务器。相同的 CLI 命令和本地工作流完全
00:04:21一样。你只是将服务器指向真实的目录或对象存储，而不是丢弃
00:04:27那个临时文件夹。对于 Git，Git 为你提供项目快照的历史记录。虽然
00:04:34在内部它做了许多巧妙的优化，但 Lore 从一开始就是围绕分块和去重来设计的。
00:04:40所以对于资产密集型的大型项目，它不需要将文件的每个新版本
00:04:47视为一个完全独立的巨大对象。Lore 还可以按需提取文件，这样你就可以使用
00:04:53包含海量数据的仓库，而不必从第一天起就下载每一个资产。
00:04:59你只需要拉取项目当前需要处理的部分。
00:05:03现在，Lore 发布时有一点让人困惑的是，它到底是中心化的还是
00:05:08分布式的。它是中心化的。有一个记录服务器，但我们所做的大部分工作
00:05:15都是在本地发生的。因此在实践中，它介于 Perforce 和 Git 之间。你既获得了中央控制权
00:05:22和访问管理，本地操作依然感觉很快，且不依赖于服务器每一秒都可用。
00:05:28它还有一些不错的区别。Lore 使用 MIT 协议，协议是
00:05:34开源的，并且有多种语言的 SDK，这使得脚本编写和构建工具更加容易。
00:05:39现在，这也是现实一点的好时机。Lore 不是我明天就会用来替换生产环境中 Perforce 的东西。
00:05:45它仍处于 1.0 版本之前。Epic Games 表示 API 可能会在第一个稳定发布版本之前发生变化，
00:05:52而且该项目显然仍在演进中。目前也没有与 Git
00:05:58的互操作性，你不能简单地将 Lore 指向现有的 Git 仓库并带入完整历史记录。
00:06:03它也是自托管的。没有一个托管服务让你创建一个账户，
00:06:09推送你的仓库然后就完成了。而且你可能看到的桌面应用并没有包含在
00:06:15开源发布中。你得到的是核心库、服务器、CLI 和 SDK。那个 GUI 不在
00:06:22其中。然后，当然还有性能问题。这性能如何？Epic 表示 Lore 可以处理大型
00:06:28仓库而不会像其他系统那样变慢。显然 Epic 在处理
00:06:33一些非常大的项目方面经验丰富。但目前，这些声明大部分来自 Epic 自己。还
00:06:39没有真正稳固的独立基准测试。所以性能看起来很有希望，但在我们真正
00:06:45开始对其进行测试之前，很难判断其性能表现。你应该使用它吗？好吧，玩一下
00:06:50是很有趣的。你在开发游戏吗？你在构建庞大的项目吗？好吧，对于新项目，也许可以。
00:06:56如果你只是想看看大型二进制资产的版本控制可能会往哪里发展，值得
00:07:01尝试一下。在非关键项目上测试它，玩玩看，看看性能如何，流程如何。
00:07:07这里更大的意义不在于 Lore 是否会很快取代 Git 或 Perforce。更大的意义在于
00:07:14一旦项目开始交付包含海量
00:07:19二进制数据的内容，版本控制就不再是一个已解决的问题。Git 赢得了文本和小文件市场。Lore 正在尝试解决那之后的问题。
00:07:27老实说，无论它是否胜出，这都是一个非常酷的方向。如果你喜欢像这样
00:07:32的编码提示和技巧，请务必订阅 Betterstack 频道。我们会在下一期视频中见到你。