共计 3268 个字符，预计需要花费 9 分钟才能阅读完成。
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 能够。
Helix Core 是来自 Perforce 的旗舰版本控制软件，是大型文件治理的最佳版本控制工具，起因如下：
二进制文件解决
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
