Git LFS 与标准 Git 的对比：对大型资产的性能影响
Git 作为基础的分布式版本控制系统，在跟踪基于文本的源代码更改方面表现出色。其效率在很大程度上依赖于内容寻址存储，该存储利用增量压缩来管理历史记录中小规模的增量更改。然而，当这种模型应用于大型二进制文件（如多媒体资产、游戏纹理或大型数据集）时，会遇到重大的性能障碍。
对于严重依赖非文本数据的项目，使用标准 Git 会迅速导致仓库臃肿、克隆时间变慢和资源效率低下。本文提供了标准 Git 与 Git 大文件存储 (LFS) 之间的全面性能比较，详细说明了它们各自的机制，并确定了何时 LFS 成为高效管理海量资产的必要优化工具。
标准 Git 的性能瓶颈
要理解 Git LFS 存在的原因，我们必须首先研究标准 Git 如何处理文件，特别是为什么这种方法对大型二进制文件无效。
内容寻址存储和历史记录
Git 的核心设计原则规定，提交的每个文件的每个版本都存储在仓库历史记录（.git 目录）中。克隆仓库时，所有历史数据——包括每个大型二进制文件的每个版本——都会传输到本地机器。
这种方法对二进制文件效果不佳，主要有两个原因：
- 低效的增量压缩： 二进制文件（如 JPEG、MP4 或编译后的可执行文件）通常已经过压缩。当对这些文件进行微小更改时，Git 难以生成有意义的增量，通常导致每个修订版本中存储的历史记录中都包含接近完整的文件副本。这会迅速加速仓库大小的增长。
- 强制性的历史记录传输： 克隆仓库需要下载整个历史记录。如果一个项目包含一个 100 MB 的纹理文件，并且该文件已被修改了 50 次，那么仅此一个资产的历史记录就可能导致初始克隆传输数 GB 的数据。这对开发速度有严重影响，特别是对于新贡献者或 CI/CD 系统。
结果： 仓库变得庞大，增加了克隆时间，减慢了后台维护任务（如垃圾回收）的速度，并需要过多的本地磁盘空间。
介绍 Git 大文件存储 (LFS)
Git LFS 是 GitHub 开发的一个开源扩展（现已得到广泛采用），它改变了 Git 处理指定文件类型的方式。LFS 将存储负担从核心 Git 仓库中转移出去，从而在外部化大型二进制文件的同时保持 Git 在源代码方面的效率。
指针系统
当一个文件被 LFS 跟踪时，实际的二进制内容不会存储在 Git 对象数据库中。相反，LFS 在 Git 仓库中存储一个小的、标准化的文本指针文件。该指针引用了实际二进制内容的位置，该内容存储在专用的 LFS 服务器上（通常与 Git 远程仓库一起托管，例如 GitHub、GitLab、Bitbucket）。
LFS 指针文件看起来如下所示：
version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
size 104857600
性能优势：即时检索
LFS 的基本性能优势在于，在克隆或获取等操作期间，Git 只检索小的文本指针。实际的大型二进制文件只在明确需要时（通常在签出操作（git checkout 或 git lfs pull）期间）才会被下载。
性能比较：LFS 与标准 Git
下表总结了在管理大型资产时，关键开发操作方面的性能差异：
| 操作 | 标准 Git 性能 | Git LFS 性能 | 优势 | 原因 |
|---|---|---|---|---|
| 初始克隆 | 差/非常慢 | 极好/快 | LFS | 只下载小的指针；按需获取二进制文件。 |
| 仓库大小 | 非常大（臃肿） | 小（轻量） | LFS | 二进制文件从 .git 目录中外部化。 |
| 签出/切换 | 慢/高 I/O | 快 | LFS | 通过 HTTP 只检索特定所需的二进制版本。 |
| CI/CD 构建时间 | 慢（因克隆巨大） | 快 | LFS | 花在克隆和获取依赖项上的时间大大减少。 |
| 历史记录审查 | 需要下载完整历史记录 | 仅指针（快） | LFS | 历史记录保持精简和可管理。 |
1. 仓库臃肿和维护
标准 Git 仓库一旦提交了大型资产，就很难清理（即使这些资产后来被删除，它们仍然保留在历史记录中）。这需要使用复杂的工具，如 git filter-branch 或 git filter-repo 来永久重写历史记录——这是一个破坏性且耗时的过程。
LFS 影响： 由于 LFS 将大文件外部化，核心 Git 仓库大小保持一致的小巧且易于管理，从而大大减少了垃圾回收（git gc）等内部 Git 流程所需的时间。
2. 带宽和网络延迟
对于分布式团队来说，网络带宽是一个主要问题。
- 标准 Git： 每个用户都必须拉取完整的仓库历史记录，无论他们实际需要哪些文件，都会为每次新克隆消耗大量的带宽。
- Git LFS： LFS 只传输与当前检出提交相关的特定二进制对象。如果用户只处理最新的发布分支，他们只会下载该特定版本所需的二进制文件，从而节省了大量带宽并加快了过程，尤其是在连接较慢的情况下。
3. 服务器负载
管理大型仓库会对 Git 服务器造成很大负载，尤其是在抓取或推送大量数据等深度操作期间。通过将大文件存储机制转移到单独的、优化的 LFS 服务器（通常使用简单的 HTTP 或类似 S3 的对象存储协议），核心 Git 服务器可以保持其在标准源代码操作方面的性能。
何时使用 Git LFS
如果文件满足以下标准，Git LFS 是最佳选择：
- 大小较大： 通常指大于 500 KB 到 1 MB 的文件。
- 二进制格式： 不太容易压缩的文件（例如，压缩的图像、视频、音频）。
- 频繁更改： 经常更新、在历史记录中生成重复版本的文件（例如，开发中的游戏资产）。
LFS 跟踪的常见候选文件：
*.psd、*.tiff、*.blend、*.max（设计/3D 资产）*.mp4、*.mov、*.wav（媒体文件）*.dll、*.exe、*.jar（编译后的二进制文件，如果提交）- 大型
*.csv、*.parquet或数据库快照（数据科学）
实现 Git LFS
实现 LFS 非常简单，只需安装 LFS 客户端并在仓库中指定应跟踪哪些文件模式即可。
步骤 1：安装和初始化 LFS
首先，确保您的机器上安装了 Git LFS 客户端。然后在仓库中运行一次安装命令：
git lfs install
步骤 2：跟踪文件类型
使用 git lfs track 告诉 Git 应使用 LFS 管理哪些文件模式。此命令会创建或更新 .gitattributes 文件，这对 LFS 正确运行至关重要。
示例：跟踪所有 Photoshop 文件和大型视频文件
git lfs track "*.psd"
git lfs track "assets/*.mp4"
# 检查对 .gitattributes 所做的更改
cat .gitattributes
# 示例输出：
# *.psd filter=lfs diff=lfs merge=lfs -text
# assets/*.mp4 filter=lfs diff=lfs merge=lfs -text
步骤 3：提交和推送
关键是，您必须将 .gitattributes 文件与被跟踪的文件一起提交。当您推送时，Git 将传输指针，而 LFS 客户端将负责将大型二进制文件上传到 LFS 存储区。
git add .gitattributes assets/
git commit -m "Added LFS tracked PSDs and MP4s"
git push
⚠️ 最佳实践：首先提交
.gitattributes
.gitattributes文件必须在跟踪它们的大文件之前或同时提交。如果您首先提交大文件，Git 将对其进行原生跟踪，从而失去了 LFS 的意义。
结论
标准 Git 在其预期目的方面是无与伦比的：对源代码和小配置文件进行版本控制。但是，当引入大型二进制资产时，由于仓库臃肿和强制性的历史记录传输，其性能会迅速下降。
Git LFS 通过抽象大型文件的存储提供了一个关键的性能优化，确保核心 Git 仓库保持轻量、快速克隆且易于维护。通过利用指针系统和即时获取，LFS 将先前缓慢的操作转变为快速流程，使其成为游戏开发、数据科学以及任何处理大量、频繁更新的二进制资产的项目的必要工具。