很多团队第一次接触 Git LFS，往往源自一次事故：仓库突然膨胀到几个 G，clone 要十几分钟，CI 动不动超时，历史包袱甩不掉。LFS 被当作“紧急止血”的方案引入，却在后续使用中暴露出更多问题：有人忘了 track，有人误提交大文件，有人在分支里来回改模型权重，结果 LFS 对象仓库越滚越大。
问题并不在工具本身，而在于团队从一开始就缺少一套清晰的LFS 配置与提交策略。这篇文章希望把 Git LFS 从“临时补丁”讲清楚，讲成一个能长期稳定运行的工程组件。
一、Git LFS 在做什么：先建立正确的心智模型
在标准 Git 里，所有文件都会被压缩进对象库，版本越多，历史越重。LFS 的做法很直接：
Git 里只存一个“指针文件”，真实的大文件交给独立的 LFS 存储服务管理。
这个指针文件本质是几行文本，记录了文件的 hash 和大小；真正的二进制内容在 push / pull 时由 LFS 客户端按需上传和下载。
这意味着两件非常重要的工程事实：
第一，Git 仓库的体积主要由指针文件决定，历史压力显著降低。
第二，大文件的生命周期管理，从 Git 历史转移到了 LFS 存储策略上。
理解这一点，后面所有配置和规范才有意义。
二、LFS 该追踪什么：配置阶段就要定边界
很多仓库的问题源于一句模糊的约定：“大文件用 LFS”。
工程上可执行的做法，需要更明确。
1️⃣ 用类型定义规则，而不是靠感觉
推荐在仓库初始化阶段就把.gitattributes写清楚，例如：
git lfs track "*.psd" git lfs track "*.zip" git lfs track "*.bin" git lfs track "models/**"这样做的好处在于：
规则跟着仓库走，新成员 clone 下来就自动生效，避免靠口头传达。
2️⃣ 明确哪些“看起来很大，但不该进 LFS”
常见反例包括：
node_modules、dist、build 产物
可通过脚本或流水线重新生成的中间文件
临时调试数据、缓存目录
这些内容更适合.gitignore，而不是 LFS。
LFS 用来管理“需要版本化的大文件资产”，这个边界要非常清晰。
三、提交策略才是关键：LFS 滥用的根源在这里
配置 LFS 只解决了“怎么存”，提交策略决定了“会存成什么样”。
1️⃣ 大文件的提交频率需要被约束
对于模型权重、设计稿、视频资源这类文件，建议遵循一个简单原则：
只提交“阶段性稳定版本”，避免高频覆盖提交。
工程上的实现方式包括：
分支内调试不 push LFS，只在合并前整理
用版本号或日期命名文件，减少覆盖式修改
在 PR 模板中显式标注是否包含 LFS 更新
这样可以显著降低 LFS 对象的累积速度。
2️⃣ 不要在历史里反复“洗大文件”
很多团队喜欢在发现问题后，用git filter-repo或git lfs migrate重写历史。
这种操作本身没有问题，但频繁进行会带来新的风险：
协作者本地仓库全部失效
CI 缓存失效
LFS 存储里遗留大量孤儿对象
更稳妥的方式是：
一次性完成迁移，之后通过流程约束避免重犯。
四、团队协作视角：把 LFS 纳入流程，而不是靠提醒
LFS 用得稳不稳，很大程度取决于流程设计。
1️⃣ 在 CI 中加一道“体积守门”
可以在 CI 里加入简单校验：
普通 Git 文件超过阈值直接失败
检查
.gitattributes是否遗漏新类型提示本次提交包含 LFS 对象变更
这类规则不会增加开发负担，却能提前阻断事故。
2️⃣ 给新成员一个“可执行”的指引
比起一篇 Wiki，更有效的是：
仓库 README 中的 LFS 使用说明
clone 后自动提示
git lfs install示例提交，明确哪些文件会进 LFS
当规范嵌入仓库本身，执行成本会降到最低。
五、一些容易被忽略的现实问题
在真实项目里，LFS 还会遇到这些情况：
存储配额与费用：尤其在 GitHub 等托管平台，LFS 流量与存储是单独计费的
离线或内网环境：需要自建 LFS Server 或镜像策略
备份与清理：定期评估 LFS 对象的实际使用情况
这些问题在项目早期看不出来，一旦规模上来，影响会非常直接。
结尾：把 Git LFS 当成资产管理系统
当你把 Git LFS 只当作“存大文件的工具”，它很容易失控。
当你把它视为版本化资产的管理系统，配置、提交策略、流程约束就会自然成型。
Git 负责代码与历史的确定性，LFS 负责重资产的有序流转。
两者边界清楚，仓库才能长期保持轻盈。
