Git LFS（Git大文件存储）被许多团队用于管理和存储大文件。在这里，我们详细介绍Git LFS是什么，它的功能是什么，何时使用它等等。
什么是Git LF
Git LFS（Git大文件存储）是一个开源的Git扩展，用于管理大文件和二进制文件，存储它们在一个单独的“LFS存储”中，以保持Git仓库的可管理大小。
今天的大多数项目既包含代码又包含二进制资产。在Git仓库中存储大型二进制文件可能会成为Git用户的瓶颈。
Git LFS是如何工作的？
Git LFS使用指向文件的指针（引用），而不是将实际文件或二进制大对象（blobs）存储在Git仓库本身中。二进制大对象是一种将二进制数据作为一个实体存储的数据类型。
因此，与将大文件/二进制大对象写入Git仓库不同，你会写一个指针文件。文件/大对象本身被写入一个单独的服务器，称为LFS存储。这样做可以实现对大文件的版本控制和对大对象的管理，同时释放Git仓库中的空间。
使用Git LFS非常简单。你只需下载扩展并配置你的文件类型。
是否要使用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大文件存储需要额外的步骤，因为你必须为每个Git仓库（即每个Git项目）设置它。这意味着对于每个仓库，你都必须安装Git LFS，告诉LFS跟踪一种文件类型，然后将跟踪信息添加到仓库中，以便当你提交该类型的文件时，它将被放入LFS存储库。对于那些对Git不够了解的用户来说，这是具有挑战性的。
Git LFS不适用于设计：
Git LFS对软件开发人员有所帮助，因为它使克隆和分支更加容易。但对于大多数与艺术设计师合作的团队来说，由于以下关键原因，它并不是一个好的解决方案：
- 它不与常见的美工和设计程序集成。
- 非编码人员如果必须从中提取资产，仍然必须支付大型二进制文件的性能代价。
- 它是一个命令行驱动的工具，因此用户必须学习一些命令来获取或提交资产。许多设计家在这方面遇到困难或不愿意这样做。虽然有一些Git LFS的图形工具，但是游戏引擎和设计工具通常与Git的集成不佳。
- 作为一个命令行驱动的工具，找到文件的正确版本也变得棘手，这使得美工设计难以对特定资产进行迭代。
基于这些原因，对于游戏开发或虚拟制作团队来说，Git LFS并不是一个理想的解决方案。
上述问题可能会减缓团队的性能。因此，即使Git本身是免费的，但在团队需要更快、更可扩展的解决方案时使用它的后果可能是昂贵的。
替代Git大文件存储的方法：
在Git中管理大文件的方式并不仅限于Git LFS。其他替代方案包括其他开源或第三方解决方案，例如：
- git-annex
- git-bigfiles
- git-fat
- git-media
- git-bigstore
- git-sym
这些选项仍然具有与Git LFS相同的问题：它们是命令行驱动的工具，与设计工具不集成，如果使用它们仍然需要获取和发送文件（这意味着你仍然需要等待），并且查找文件的最新版本具有挑战性。有一种更好的方式来管理大文件和二进制文件。