一、简介
Git LFS(Git Large File Storage)是由 GitHub 开发的一款 Git 扩展工具,旨在帮助开发者更高效地管理仓库中的大文件。传统 Git 会将文件的每个版本完整存储在仓库历史中,导致大文件(如音频、视频、数据集、二进制文件等)快速膨胀仓库体积,影响克隆和推送效率。Git LFS 通过以下机制解决这一问题:
核心原理
- 指针替换:在提交时,将大文件替换为轻量级的文本指针(Pointer File),仅几 KB 大小,包含原文件的元信息(如哈希值、存储路径)。
- 远程存储:大文件实际内容被存储在 Git LFS 服务器(如 GitHub、GitLab 提供的服务,或自建服务器),与代码仓库分离。
- 按需下载:克隆或切换分支时,Git LFS 会根据指针文件从远程服务器下载当前需要的大文件版本,而非全部历史版本。
工作流程
- 安装:先安装 Git LFS 客户端(官网下载),并在仓库中初始化:
bash
git lfs install
- 跟踪文件:指定需要使用 LFS 管理的文件类型或路径(支持通配符):
bash
此操作会生成git lfs track "*.mp4" # 跟踪所有 MP4 文件 git lfs track "data/*" # 跟踪 data 目录下的所有文件
.gitattributes
文件并自动提交,记录跟踪规则。 - 正常提交:添加、提交和推送文件时,Git LFS 会自动处理大文件:
bash
推送时,大文件会上传至 LFS 服务器,代码仓库仅包含指针。git add video.mp4 git commit -m "添加视频文件" git push origin main
- 克隆仓库:使用
git clone
时,LFS 文件会自动下载:bash
若只需代码而不下载大文件,可使用:git clone https://example.com/repo.git
bash
后续按需下载指定文件:git lfs clone --skip-smudge https://example.com/repo.git
bash
git lfs pull --include="video.mp4"
主要优势
- 仓库体积显著减小:避免大文件占用过多空间,提升克隆速度。
- 版本控制更高效:仅需管理轻量级指针,历史记录更清晰。
- 协作友好:团队成员可选择性下载需要的大文件,节省带宽。
- 兼容性强:与现有 Git 工作流程无缝集成,无需改变使用习惯。
注意事项
- 存储成本:部分托管平台(如 GitHub)对 LFS 存储和带宽有限额,超出需付费。
- 依赖外部服务:需确保 LFS 服务器可用,否则可能影响文件访问。
- 历史清理复杂:若误提交大文件到普通 Git 历史,需使用
git filter-repo
等工具清理。
Git LFS 适合需要在 Git 仓库中管理大文件的场景,尤其在音视频制作、机器学习(数据集)、游戏开发(资源文件)等领域应用广泛。
二、Git LFS的使用过程
1.创建文件夹,使用git init
# 在当前目录初始化一个新的 Git 仓库 git init
2.在该仓库下安装Git LFS
15155@MM MINGW64 /e/Git_Projects/MDK (main)
$ git lfs install
Updated Git hooks.
Git LFS initialized.
验证
$ git lfs version
git-lfs/3.5.1 (GitHub; windows amd64; go 1.21.7; git e237bb3a)
3.配置跟踪规则
在仓库中指定哪些文件需要使用 LFS 管理,支持通配符(如 *.mp4
、data/*
)。
方式一:命令行直接跟踪
bash
git lfs track "*.mp4" # 跟踪所有 MP4 文件
git lfs track "data/*" # 跟踪 data 目录下的所有文件
git lfs track "model.h5" # 跟踪特定文件
执行后,Git LFS 会自动创建或更新 .gitattributes
文件(需提交该文件)。
$ git lfs track "*.zip"
Tracking "*.zip"
产生文件
方式二:手动编辑 .gitattributes
直接在仓库根目录创建或编辑 .gitattributes
文件,添加类似以下内容:
plaintext
*.mp4 filter=lfs diff=lfs merge=lfs -text
data/* filter=lfs diff=lfs merge=lfs -text
4.提交Git LFS配置文件,目标大文件和推送到运程的目标大文件
添加、提交和推送文件的操作与普通 Git 流程一致,但大文件会自动上传到 LFS 服务器:
bash
git add .gitattributes # 提交跟踪规则
git add video.mp4 # 添加大文件(实际只提交指针)
git commit -m "添加视频文件"
git push origin main # 推送时,大文件会上传到 LFS 服务器
(1)提交配置
$ git add .gitattributes
(2)查看大文件
$ ls -al
total 813758
drwxr-xr-x 1 28970 197609 0 Jul 27 10:24 ./
drwxr-xr-x 1 28970 197609 0 Jul 27 09:55 ../
drwxr-xr-x 1 28970 197609 0 Jul 27 10:27 .git/
-rw-r--r-- 1 28970 197609 43 Jul 27 10:24 .gitattributes
-rw-r--r-- 1 28970 197609 833276817 Jul 16 22:16 MDK528.zip
-rw-r--r-- 1 28970 197609 39 Jul 27 09:45 README.md
(3)暂存目标大文件
$ git add MDK528.zip
(4)提交到本地
$ git commit -m "Firstly,commit a big MDK_Setup_package."
[main 39e1935] Firstly,commit a big MDK_Setup_package.2 files changed, 4 insertions(+)create mode 100644 .gitattributescreate mode 100644 MDK528.zip
(5)推送至远程
$ git push origin main
Uploading LFS objects: 100% (1/1), 833 MB | 3.6 MB/s, done.
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 20 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 498 bytes | 249.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To github.com:Molesidy/MDK.git58bc491..39e1935 main -> main
5.成功提交并上传大文件
注:普通git不能传输超过100MB的文件,而git lfs在github上最大支持2GB;
普通的免费 GitHub 仓库建议最大存放 1GB 的文件:
GitHub 虽未对免费仓库设置严格的硬性容量上限,但建议将仓库大小保持在 1GB 以内,理想情况是小于 5GB。若超过该大小,可能会收到 GitHub 支持团队要求减小仓库大小的邮件。此外,免费账户单个文件不能超过 100MB,若文件大于 50MB 会收到警告,若通过浏览器上传文件,则不得大于 25MB。
三、补充说明1
Git LFS 的文件大小限制取决于具体的存储提供商和客户端配置,而非 Git LFS 本身。以下是常见场景的限制说明:
1. 不同平台的文件大小限制
平台 | 免费版限制 | 付费版限制 |
---|---|---|
GitHub | 单个文件 ≤ 2GB | 单个文件 ≤ 5GB(需联系支持) |
GitLab | 单个文件 ≤ 10GB(取决于实例配置) | 企业版可提升限制 |
Bitbucket | 单个文件 ≤ 2GB | 单个文件 ≤ 5GB(需联系支持) |
AWS CodeCommit | 无明确限制(受 S3 存储桶限制) | 无明确限制 |
自建服务器 | 取决于服务器配置(如 Nginx/Apache 限制) | 自定义配置 |
- 注意:即使平台支持大文件,上传速度也可能受网络和服务器性能影响。
2. 客户端配置限制
Git LFS 客户端默认没有严格的文件大小上限,但可能受以下因素影响:
- HTTP 请求大小限制:如果使用 HTTP 协议传输,服务器(如 Nginx、Apache)可能限制最大请求体大小。例如:
bash
# Nginx 配置示例(需修改 nginx.conf) client_max_body_size 10G;
- 内存和磁盘空间:上传 / 下载大文件时,客户端需要足够的临时空间缓存数据。
3. 突破限制的方法
- 使用专业存储服务:对于超大文件(如数十 GB),可考虑将文件存储在云存储(如 S3、Google Cloud Storage),仅在 Git 中记录下载链接。
- 分块处理:将大文件分割为多个小文件(如使用
split
命令),分别管理。 - 联系平台支持:企业版用户可联系 GitHub/GitLab 等平台提升限制。
4. 最佳实践
- 避免超大型文件:尽量将单个文件控制在 1GB 以内,过大的文件会显著降低协作效率。
- 使用
.gitattributes
严格过滤:仅对必要的大文件使用 LFS,避免意外提交不需要的大文件。 - 定期清理历史:使用
git lfs prune
清理不再需要的本地 LFS 文件。
总结
Git LFS 的实际文件大小限制因平台而异,免费版通常支持 2GB 以内,付费版或自建服务器可扩展到更大。在使用前,建议查看对应平台的文档或联系技术支持确认具体限制。
四、补充说明2
对于免费 GitHub 用户,单个仓库内的 Git LFS 文件最大支持 2GB,这一结论是正确的。以下是具体细节和限制说明:
1. 单个文件大小限制:2GB(免费版明确支持)
根据 GitHub 官方文档,免费用户的 Git LFS 文件大小限制为:
- 单个文件上限:2GB(付费版如 GitHub Team 为 4GB,GitHub Enterprise Cloud 为 5GB)。
- 超出处理:若上传超过 2GB 的文件,Git LFS 会直接拒绝并报错。
例如,用户上传一个 2.1GB 的视频文件时,会收到类似以下的错误提示:
bash
error: The file "large_video.mp4" is 2.1 GB; this exceeds GitHub's file size limit of 2.0 GB for Git LFS files.
2. 仓库总存储量限制:所有仓库共享 1GB
尽管单个文件支持 2GB,但免费用户的所有仓库的 LFS 文件总存储量被限制为 1GB。例如:
- 若在多个仓库中分别上传 2 个 1GB 的 LFS 文件,总存储量将达到 2GB,超出免费配额,导致后续上传失败。
- 需通过 GitHub 账户设置中的Billing and plans页面查看实时用量。
3. 带宽配额:每月 1GB(所有仓库共享)
免费用户的 LFS 文件下载和上传带宽每月总计 1GB。例如:
- 若一个 2GB 的 LFS 文件被下载 5 次,总带宽消耗为 10GB(远超免费配额),此时文件将无法继续下载,需升级付费计划。
4. 常见误区与注意事项
(1)仓库总大小与 LFS 存储的区别
- 仓库总大小:GitHub 建议免费仓库总大小控制在 1GB 以内(含普通文件和 LFS 指针文件),但这是软性建议,非硬性限制。
- LFS 存储量:仅计算实际存储在 GitHub LFS 服务器上的大文件内容,不包含仓库中的普通文件和指针文件。
(2)LFS 指针文件不占用存储配额
Git LFS 在仓库中存储的是轻量级指针文件(约 1KB),这些文件不计入 1GB 的 LFS 存储配额。例如:
- 即使仓库中有 1000 个 LFS 指针文件,它们的总大小仍可忽略不计。
(3)历史文件清理的重要性
- 未引用的 LFS 文件:即使文件被删除或从仓库历史中移除,其内容仍可能保留在 LFS 存储中,继续占用配额。
- 清理方法:使用
git lfs prune
命令清理本地未引用的 LFS 文件,或通过 GitHub API 删除远程未引用的对象。
5. 突破限制的可行方案
(1)拆分大文件
- 将单个 2GB 以上的文件拆分为多个 2GB 以内的片段(如使用
split
命令),分别上传。 - 示例:
bash
split -b 2G large_file.iso large_file_part_
(2)混合使用 LFS 和外部存储
- 对超过 2GB 的文件,将其存储在云存储(如 AWS S3、Google Cloud Storage),仅在 Git 中记录下载链接。
- 示例:
markdown
# 下载大文件的说明 1. 访问 [S3链接](https://example-bucket.s3.amazonaws.com/large_model.pth) 2. 将文件放置在 `models/` 目录下
(3)升级付费计划
- GitHub Team($4 / 用户 / 月):提供 50GB 存储 + 50GB / 月带宽,单个文件支持 4GB。
- GitHub Enterprise Cloud:支持 5GB 单个文件,存储和带宽配额更高。
总结
免费 GitHub 用户的单个仓库内的 Git LFS 文件最大支持 2GB,但需注意以下全局限制:
- 所有仓库的 LFS 文件总存储量:1GB。
- 每月带宽配额:1GB。
- 仓库总大小建议:控制在 1GB 以内(含普通文件和指针文件)。
若需频繁处理大文件,建议结合外部存储或升级付费计划,以避免因配额不足影响协作。