必须用git lfs管理单个超50mb且频繁变更的二进制文件，否则克隆卡死、仓库膨胀；git lfs install须在track前执行以注入钩子和filter规则，新克隆仓库需单独运行该命令。
只要你的仓库里有单个超过 50MB 的二进制文件（比如 .psd、.onnx、.zip），且它会随提交变更，就必须用 Git LFS —— 否则 git clone 会卡死，git checkout 可能失败，仓库体积会指数级膨胀。
git lfs install 必须在 track 前执行，且不能跳过
git lfs install 不是“装完就完”，它是往全局 ~/.gitconfig 写 filter 规则，并在 .git/hooks/ 放钩子脚本。这些钩子负责在 git add 时把大文件替换成指针。
- 如果先
git add big_file.psd再git lfs install，这个文件已经进 Git 对象库了，LFS 完全无效 -
git lfs install --skip-repo是安全做法：避免误初始化当前目录，等你确认要启用 LFS 时再进项目目录运行git lfs install - 新克隆的仓库必须单独运行
git lfs install；--system全局注册不推荐——不同项目可能依赖不同 LFS 版本，容易冲突
git lfs track 的写法和常见陷阱
git lfs track 修改的是 .gitattributes，不是 .gitignore。它只声明“哪些路径交给 LFS 处理”，不决定是否忽略。
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 正确：
git lfs track "*.psd"→ 生成*.psd filter=lfs diff=lfs merge=lfs -text - 错误：
git lfs track "data/models/*.bin"→ Git 2.22+ 才支持这种递归通配符，旧版本直接报错或不生效 - 若目标文件已存在且未提交，先
git rm --cached data/models/large.bin，再track，再git add .gitattributes data/models/large.bin - 每次改完
.gitattributes，必须git add .gitattributes && git commit，否则远程仓库不知道该用 LFS
克隆和拉取大文件的实际流程
默认 git clone 会自动触发 LFS 文件下载（即 “smudge” 过程），但网络不稳定时容易中断。生产环境建议分两步操作：
- 先禁用自动拉取：
GIT_LFS_SKIP_SMUDGE=1 git clone <url></url>（注意等号两边不能有空格） - 进目录后手动拉取：
git lfs pull，可加-I "file1.zip,file2.onnx"指定文件，或-X ".tmp"排除临时类型 - 验证是否成功：
git lfs ls-files列出所有被管理的文件，ls -lh看实际大小 —— 如果还是指针内容（几行文本），说明没拉下来
历史大文件迁移和清理必须重写提交
如果大文件已经提交进历史，git rm --cached 只删暂存区，对象仍留在 Git 数据库里。必须用 git filter-repo 或 git lfs migrate 彻底清除。
- 迁移已有历史中的
.psd：git lfs migrate import --include="*.psd" --everything，它会重写全部提交，把历史里的 PSD 全转成 LFS 指针 - 清理误传的大文件（如已推到远程）：先
git filter-repo --path-glob "*.zip" --invert-paths，再git push --force --all - 注意：这类操作不可逆，务必先备份裸仓库（
git clone --mirror）
最常被忽略的一点：LFS 不是“设好就自动工作”。每个新克隆的仓库都要自己运行 git lfs install，每个新跟踪的文件类型都要提交 .gitattributes，每次拉取失败都得查 git lfs ls-files -l 看状态 —— 它没有魔法，只有明确的步骤和可验证的状态。
