Git 推出大文件储存工具 Git LFS，但它真的好用吗？

Git LFS（全称为 Git Large File Storage，Git 大文件存储）被许多团队用来管理和存储大文件。本篇文章将解释 Git LFS 是什么，它的功能和使用场景，以及它究竟是不是管理大文件的最佳版本控制工具。

什么是 Git LFS（Git 大文件存储）？

Git LFS 是一种开源的 Git 扩展，用于管理大文件和二进制文件，将它们存储在单独的 "LFS 存储库" 中， 从而让 Git 存储库保持在一个可管理的规模。

如今，很多的项目都包含代码和二进制资产。将大型二进制文件存储在 Git 存储库中可能会成为 Git 用户的瓶颈。

Git LFS 存储如何工作？

Git 大文件存储使用指针来引用文件，而不是将实际文件或二进制大对象（blobs，一种将二进制文件存储为一个实体的数据类型） 存储在 Git 存储库本身中。

因此，大文件/二进制大对象不会被直接写入 Git 存储库，而是被写入一个指针文件。文件/二进制大对象本身会被写入一个单独的服务器，称为 LFS 存储库。通过这种方式，可以对大文件进行版本控制，以及管理二进制大对象，同时释放 Git 存储库的空间。

我应该使用 Git LFS 吗？

如果您需要在 Git 中管理大文件或二进制文件，那么可以考虑使用 Git LFS。（但是，如果您的团队中有美术人员和设计师，需要对他们的大型二进制艺术文件进行版本控制，那么您可能不希望使用 Git LFS。关于这一点，我们将在下一节中详细讨论。）

使用 Git LFS 或其他替代方案的原因是，Git 是一种分布式版本控制系统，每个开发人员在本地计算机上都有完整的变更历史记录。对大型二进制文件进行更改会导致什么？每次更改文件并提交后，Git 存储库的规模都会根据文件的大小而增加。这意味着获取文件会花费很长时间，并且很难对这些二进制文件进行版本控制和合并。

因此，每当文件增长时，Git 存储库也会增长，这会导致 Git 用户在检出和克隆存储库时出现性能下降的情况。

Git LFS 是为解决这些问题而创建的，但它自身也存在一些问题和限制。

Git LFS 的问题

Git LFS 虽然有效，但许多使用它的团队发现其管理起来较为困难。以下是考虑寻找 Git LFS 替代方案的一些原因：

设置 Git LFS 非常耗时

要使用 Git LFS，每个用户都必须在其服务器和工作站上安装它。这样做很耗时，对管理员来说也是一种负担。而且一旦安装完成，对 Git LFS 的可见性和控制性都较低。

维护 Git LFS 需要额外的步骤

维护 Git LFS 需要额外的步骤，因为您必须为每个 Git 存储库（即每个 Git 项目）设置 Git LFS。这意味着每个存储库都需要安装 Git LFS，您还需要告诉 LFS 要跟踪的文件类型，然后将跟踪信息添加到存储库中，以便在提交该类型的文件时，它将被放置在 LFS 存储库中。对于还不太了解 Git 的用户来说，这颇具挑战性。

Git LFS 不适用于美术团队

Git LFS 对于软件开发人员来说是有帮助的，因为它使克隆和分支更加容易。但对于大多数需要与美术人员或设计师协作的团队来说，出于以下几个关键原因，它不是一个好的解决方案：

• 它不与流行的美术和设计软件集成；

• 非编码人员仍然需要承受从 Git LFS 拉取其资源时的性能损失；

• 它是一个基于命令行的工具，因此用户必须学习一些命令才能获取或提交资产。许多美术人员会在这方面遇到困难，或者他们根本不愿这么做。虽然有一些图形化的 Git LFS 工具，但游戏引擎和设计工具与 Git 的集成较差；

• 作为基于命令行的工具，查找文件的正确版本也变得复杂，这使得美术人员难以迭代特定资产。

因此，对于游戏开发或虚拟制作团队来说，Git LFS 并不是一个理想的解决方案。

上述问题会影响团队的绩效。因此，尽管 Git 本身是免费的，但当您的团队需要更快、更具可扩展性的解决方案时，使用它的成本可能是昂贵的。

Git LFS 的替代方案

Git LFS 并不是在 Git 中管理大文件的唯一方式。替代方案包括其他开源或第三方修复程序，例如：

• git-annex

• git-bigfiles

• git-fat

• git-media

• git-bigstore

• git-sym

这些选项仍然存在与 Git LFS 相同的问题：它们是基于命令行的工具，不与美术或设计工具集成，如果使用它们，您仍然需要获取和发送文件（意味着仍然需要等待），而且找到一个文件的最近版本很具挑战性。您需要一种更好的方式来管理大型文件和二进制文件。

存储大文件的最佳版本控制工具：Perforce Helix Core

现在的项目比以往都大得多，其中包含许多的文件和混合资产。Git 和 Git LFS 根本无法版本控制它们，但 Perforce Helix Core 可以。

https://www.perforce.com/vcs/high-latency-optimized-network，是大型文件管理的最佳版本控制工具，原因如下：

二进制文件处理

Perforce Helix Core非常适合管理大型二进制文件。在 Perforce Helix Core 中，大文件存储是一种原生的能力，而不是附加组件。它让您能够将二进制文件与源代码一起存储。实际上，您的所有最大文件——二进制文件、源代码、艺术文件、视频文件、图像、库和构建产物等，都可以存放在单个储存库中。将所有资产存储在一个储存库中可以让分散的团队更快地行动。

可扩展性

Perforce Helix Core 能够随着团队的全球扩展而扩展。Git 通常通过距离用户数千英里的单个服务器访问，而使用 Git LFS 时，用户仍然必须通过网络获取他们需要的二进制文件。得益于分布式架构，Perforce Helix Core 可以通过边缘服务器访问，将资产放置在靠近用户的位置，从而使他们更快地获取这些资产。

安全

在 Perforce Helix Core 中，您可以将权限设置为单个文件和 IP 地址，因此团队成员和外部贡献者只能访问他们需要的文件，或者您认为他们需要的文件。这减少了数据量，并保护了您的知识产权。您无法在本地 Git 中执行此操作，即使您使用类似 GitHub 这样的 Git 管理器，也只能为每个储存库或分支设置权限，而不能为单个文件设置权限。

协作

对于在数字资产上协作的团队来说，Perforce Helix Core 比 Git LFS 更好，因为它提供了更好的文件锁定功能。LFS 的“文件锁定”功能实际上只是一个“存储库锁定”，就是当更改中包含被其他用户锁定的文件时，此功能会阻止这个更改被推送到主储存库。

而 Perforce Helix Core 采用的是真实的文件锁定策略。如果您尝试提交一个包含已锁定文件的待处理更改列表，您会收到错误提示。如果发生这种情况，您可以轻松地从更改列表中删除已锁定的文件并提交其他内容。此外，全局锁定可见性有助于在第一时间防止冲突发生。不会有冲突，也不会有不必要的更改。

如果您想将您的 Git LFS 仓库迁移到 Perforce Helix Core，并保留历史记录，即使其中存储了数百 GB 的二进制数据，请联系Perforce中国授权合作伙伴——龙智，我们的专家团队将为您提供专业建议。

顺便说一下，Perforce 也有 Git

您是否有需要使用 Git 的团队？Perforce 为您提供了多个选项。如果您同时使用Perforce Helix Core和 Git，您可以使用免费的 Git 连接器将 Git 资产简单地镜像到 Perforce Helix Core 中，该连接器对于已获得 Perforce Helix Core 许可的客户免费。此外，Perforce 还通过 Helix TeamHub 为存储在 Helix Core 中的 Git 资产提供了代码审查工具。当以这种方式配置时，Helix TeamHub 对于持有 Perforce Helix Core 许可的用户也是免费的。

Helix TeamHub也可以独立于 Perforce Helix Core 使用，可以在云端或本地部署。在这种方式下，它不仅可以用于托管 Git 储存库，还可以用于 SVN、Mercurial、WebDav、Ivy、Maven 和 Docker 储存库。

您的团队可以从 5 个用户和 1GB 的存储空间开始免费使用，随着团队规模的增长逐步付费。

文章来源：https://bit.ly/3mLVmdx