最近在学习 Git LFS，把一些零散的笔记整理成一篇博文，记录我的学习思路与心路历程。以下内容均为个人理解总结，部分尚未在生产项目中验证，仅供回顾与参考。
🔍 Git LFS 是什么？原理是什么？
刚接触 Git 时，就听说它“不擅长管理大文件”，尤其是模型文件、音视频资源、打包产物等动辄几百 MB 或 GB 的二进制文件。Git LFS（Large File Storage）就是为了解决这类问题而诞生的扩展组件。
✅ 本质
Git LFS 不是对 Git 本体的修改，而是通过引入一个“指针文件”的概念，将 Git 的版本控制与大文件的实际存储解耦。Git 只记录一份几十字节的指针，大文件内容由 Git LFS 存储服务托管（可为 GitHub、GitLab、阿里 OSS 或自建服务）。
📄 指针文件示例：
version https://git-lfs.github.com/spec/v1
oid sha256:<hash>
size <bytes>
每次 git commit 时，Git 只记录这段简短的指针信息，而大文件通过 LFS 上传至后端存储。
🔁 Git 工作流对比
| 功能 | 普通 Git | Git LFS |
|---|---|---|
| 大文件存储方式 | 存入 .git/objects | 存储指针，实际文件走 LFS |
| 历史版本管理 | 每次修改保留完整副本 | 指针管理版本，大文件共用 |
| clone 时下载内容 | 全历史版本 | 默认仅当前分支所需内容 |
🎯 Git LFS 能解决哪些痛点？
在学习中我总结了几个关键优势：
1. 突破平台文件大小限制
GitHub / GitLab 对单个文件通常有 100MB 或 200MB 限制，Git LFS 可以绕开该限制，透明地上传大文件。
2. 解决仓库膨胀与冗余
- 普通 Git：200MB 文件改动 10 次，仓库增至 2GB；
- Git LFS：指针 + 共享文件体，clone 默认只拉最新版本，仓库更轻量。
3. 提升 Git 操作效率
减少 Git 的磁盘 I/O 与对象处理，checkout、clone、切分支等操作更快，体验更流畅。
📌 注意： 如果 Git 仓库和 LFS 服务部署在同一台服务器，磁盘空间占用不会减少，但 Git 本体性能会提升。
🚀 为何 checkin / checkout 会更快？
✅ Checkin（提交）：
- 普通 Git：每次提交大文件都产生完整新副本；
- Git LFS：仅写入小指针，二进制文件另走通道上传。
✅ Checkout（切换版本）：
- 普通 Git：解压全部历史数据到工作区；
- Git LFS：恢复指针 + 按需并行下载大文件，仅拉取当前所需内容。
⚙️ 在 Gerrit 中配置 Git LFS
1. 安装 LFS 插件
将官方或社区版本的 lfs.jar 插件放入 Gerrit 的 plugins/ 目录。
2. 修改 etc/gerrit.config
[lfs]plugin = lfs
3. 新建 etc/lfs.config，配置后端存储方式
可选任意一种，测试使用第一种就行了
📁 本地存储（默认）
[storage]backend = fsdirectory = /data/gerrit/lfs-custom #本地路径，可不填，默认/data/lfs
适用于测试环境、小团队或 <500GB 的部署。
☁️ Amazon S3 存储
[storage]backend = s3bucket = gerrit-lfs-bucketregion = us-west-1accessKey = AKIAXXXXXXXXXsecretKey = xxxxxxxxxxxxendpoint = https://s3.us-west-1.amazonaws.com # 可选
可兼容 MinIO、Ceph 等 S3 接口，适合大文件托管。
🌐 阿里云 OSS（S3 协议）
[storage]backend = s3bucket = gerrit-lfs-ossregion = oss-cn-hangzhouaccessKey = LTAI5tXXXXXXXXXXXsecretKey = xxxxxxxxxxxxxendpoint = https://oss-cn-hangzhou.aliyuncs.com
适配国内企业、支持 CDN 加速和数据生命周期管理。
🔧 自定义 HTTP 存储
[storage]backend = customurl = http://lfs.mycompany.com/api/objectsauthHeader = Authorization: Bearer xxxxxxxx
适用于自研服务或集成 Artifactory 等系统。
🧩 多策略混合存储（高级用法）
[storage "images"]backend = fsdirectory = /data/gerrit/lfs-imagesinclude = **/*.png, **/*.jpg[storage "videos"]backend = s3bucket = gerrit-lfs-videosregion = ap-southeast-1include = **/*.mp4, **/*.mov
图片走本地，视频走云存储，冷热数据分离、灵活控制成本。
4. 启用 All-Projects 中的 LFS 支持
git clone ssh://admin@mygerrit.com:8011/All-Projects
cd All-Projects
git fetch origin refs/meta/config
git checkout FETCH_HEAD
vi lfs.config
编辑配置文件：
[lfs "^.*"]enabled = truemaxObjectSize = 1024m
保存后提交配置：
git add .
git commit -m "Enable LFS for all projects"
git push origin HEAD:refs/meta/config
5. 重启 Gerrit & 验证
- 重启 Gerrit 服务；
- 在 Plugins > Installed 中确认
lfs插件存在； - 上传/下载大文件测试是否生效。
👩💻 用户端使用流程（学习记录）
1. 上传
确保 Git 版本 ≥ 1.8.2，安装 Git 和 Git LFS：
Ubuntu：
curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
sudo apt-get install git-lfs
CentOS：
yum install epel-release
yum install git
curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.rpm.sh | sudo bash
yum install git-lfs
初始化 LFS：
# cd进到仓库后
git lfs install # 初始化 Git LFS 钩子
设置追踪文件类型（根据实际场景修改）：
git lfs track "*.iso" # 指定需要使用 LFS 管理的文件类型
查找大文件（>50MB）：
find . -size +50M
输出例如：
./gigi.a
./bobo.a
添加跟踪（会自动写入并生成 .gitattributes 文件）：
git lfs track "gigi.a"
git lfs track "bobo.a"
把 .gitattributes 文件加入 Git 仓库：
git add .gitattributes
检查跟踪规则：
git lfs track
查看当前 LFS 文件：
git lfs status
执行常规 Git 操作：
git add .
git commit -m "Add large files via LFS"
git push origin master
如果 gerrit 服务器没有配过 lfs，将出现报错：
fatal: Gerrit Code Review: git-lfs-authenticate: not found: exit status 1
若需推送到指定分支：
git push origin local-branch:remote-branch
💡 Git 不支持推送空目录。
2. 下载
重复前述安装步骤，clone 后执行：
git lfs pull
🔁 Git LFS 与 CI/CD 的结合思考
在 CI/CD 中，如果只 git clone，工作目录中的大文件可能仍是指针文件，导致构建或测试失败。我的学习记录如下：
stages:- buildbuild:script:- git lfs install- git lfs pull # 拉取当前分支所需的大文件- python run_model.py
✅ 补充说明
- 缓存优化：缓存
.git/lfs可避免每次都拉大文件； - 带宽/额度控制：公共 LFS 服务可能有限额，自建或对象存储拉取是更稳妥方案。
🧠 总结体会
“大文件管理的关键，不在于强塞进 Git，而是借助专业系统处理。”
- Git LFS 让 Git 仓库保持轻量，提升团队协作体验；
- 学习过程中，重点理解其 “指针机制 + 按需下载”；
- 配置方面，平台（如 Gerrit、GitHub、GitLab）差异虽有，但本质思路一致；
- 在 CI/CD、Docker 等场景也可无缝集成，扩展性强。