git查分支大文件需用git rev-list --objects结合git cat-file --batch-check批量获取对象大小，再映射路径定位首次引入提交；lfs文件需单独解析.gitattributes并调用git lfs ls-files检测。
Git如何查出某个分支里体积超限的文件
Git本身不直接提供“按大小筛选文件”的命令，但可以组合 git ls-tree 和 git cat-file 拿到每个 blob 的实际大小。关键在于：必须用 git ls-tree -r --long <branch></branch> 获取所有文件对象的 SHA1 和路径，再对每个 SHA1 调用 git cat-file -s <sha1></sha1> 查体积——因为 ls-tree 输出的 size 是“树中记录的大小”，不可信（尤其对 Git LFS 或已过滤的文件）。
- 别用
du -sh或ls -l查工作区，那反映的是检出后的内容，不是 Git 对象大小 - 如果分支未检出，脚本仍需能运行，所以必须基于对象数据库操作
- 大文件可能在历史提交中存在、当前分支已删，但若没被 GC，仍占空间——预警应覆盖整个分支可访问的历史（用
git rev-list <branch></branch>+git ls-tree -r更准）
Shell脚本里怎么高效遍历并过滤出大于10MB的blob
逐个调用 git cat-file -s 在几千个文件时会明显变慢。优化方式是：先用 git rev-list --objects <branch></branch> 一次性导出所有对象及其路径，再用 git cat-file --batch-check='%(objectname) %(objectsize:disk)' 批量查尺寸——这是 Git 2.22+ 支持的高效模式，比循环快 5–10 倍。
- 示例核心片段：
git rev-list --objects main | cut -d' ' -f1 | git cat-file --batch-check='%(objectname) %(objectsize:disk)' | awk '$2 > 10485760 {print $1}' | git cat-file --batch='%(objectname) %(objecttype) %(objectsize:disk) %(rest)' -
%(objectsize:disk)是真实存储大小（含压缩），比%(objectsize)更准确 - 注意：
--batch-check输入必须是纯 SHA1 列表，不能带路径；路径需另存映射，否则无法关联到具体文件名
为什么脚本常漏掉Git LFS跟踪的大文件
Git LFS 文件在仓库里只存一个文本指针（oid），其 blob 大小通常只有几百字节，git cat-file -s 查不到真实体积。真正的大文件在 LFS 存储服务中，本地 Git 对象数据库不感知。
- 检测前必须先判断是否启用 LFS：
git lfs ls-files是否有输出 - 若启用，需额外解析
.gitattributes中的filter=lfs规则，匹配路径后查 LFS 的git lfs ls-files --all --long输出中的 size 字段 - 常见坑：脚本只扫 Git 对象，却对
model.bin这类 LFS 文件完全静默，误判为“无大文件”
预警触发后怎样定位到首次引入该文件的提交
知道文件大没用，得知道谁、什么时候加进来的。用 git log --oneline --reverse -- <path></path> 可以拿到首次提交，但前提是路径已知——而前面查出的是 blob SHA1，不是路径。所以必须在查大小阶段就保留 SHA1 → 路径的映射。
- 推荐做法：用
git ls-tree -r --long <branch></branch>先建一张表（SHA1 + 路径），再批量查 size，最后 join 匹配 - 对每个超限 blob，执行
git log -1 --pretty=%H -- <path></path>得到引入提交哈希，再git show --stat <commit></commit>看上下文 - 注意：同一文件可能在多个提交中修改，但首次添加才是根因；别用
git log --all，它会跨分支干扰结果
真正难的不是找出大文件，而是区分“合理的大文件”（比如数据集、预训练模型权重）和“意外的大日志/临时文件”。脚本里硬编码排除规则容易失效，更稳妥的是把预警结果连同首次提交作者、时间、变更行数一起输出，交由人工快速判断——毕竟 Git 不知道你的业务语义。
