当git push被拒且错误信息含“exceeds quota 100mb”“file xxx is 125.67mb”或“gh001: large files detected”，即可确认为单文件体积超限；需用git verify-pack定位历史中真实超限blob，再以git filter-repo安全清理。
git push 被拒时怎么确认是单个文件超限？
错误信息里明确出现 exceeds quota 100MB、File xxx is 125.67MB 或 GH001: Large files detected，基本可锁定为单文件体积超限。注意区分「总包大小超限」和「单文件超限」——Git 推送失败绝大多数不是网络或权限问题，而是远程 pre-receive hook 主动拦截，且拦截日志会直接给出超标文件路径和精确字节数。
常见误判点：write error: Broken pipe 或 fatal: The remote end hung up unexpectedly 看似是网络中断，实则大概率是服务端检测到大文件后提前终止连接。此时应优先查错误日志末尾，而非重试或调 http.postBuffer。
如何快速定位历史中真正超限的 blob 文件？
不能只看工作区或最新提交——大文件可能藏在几个月前某次 CI 构建提交里。可靠方法是用 Git 原生命令扫描所有对象：
-
git verify-pack -v .git/objects/pack/*.idx | grep '^.' | sort -k3 -n | tail -10：列出 pack 中最大的 10 个 blob 对象（第三列为字节数） - 拿到最大 blob 的 hash（如
bc55a65f266bdf6017ac8e5cf8411b6a14354f18）后，用git rev-list --all --objects | grep bc55a65f266bdf6017ac8e5cf8411b6a14354f18反查路径 - 若返回多行，说明该 blob 在多个提交中复用；若无输出，需配合
git show --name-only <commit-hash></commit-hash>手动翻找
PowerShell 用户注意：Where-Object 和 Sort-Object 性能远低于原生 grep/sort，建议切到 WSL 或 Git Bash 执行。
git filter-repo 删除历史大文件的最小安全操作集
git filter-branch 已被官方弃用，git filter-repo 是当前唯一推荐方案。关键在于避免污染原仓库：
- 先克隆干净副本：
git clone --no-local --bare origin-url clean-repo.git（--bare能跳过工作区，更快） - 进入目录后执行：
git filter-repo --path 'path/to/bigfile.zip' --invert-paths --force（--invert-paths表示保留其他所有文件） - 删完立刻验证：
git count-objects -vH查看对象体积是否显著下降；再用前述verify-pack命令确认目标 blob 是否消失 - 强制推送前，务必检查远程分支保护规则——很多团队启用了
Require pull request reviews，--force会被直接拒绝
警告：--force 推送会改写所有提交哈希，协作分支必须同步通知所有人重置本地分支，否则后续 pull 会出错。
合并分支时触发超限，本质是合入了含大文件的历史
你以为只是 merge 一个 feature 分支，但该分支某次提交曾引入 dist/app.bundle.js，哪怕你后来删了它，merge 操作仍会把整个历史链带进来。所以「合并失败」的真实原因是「目标分支历史中首次出现该大文件」。
临时解法（不推荐长期用）：
- 在 merge 前，用 git log --oneline feature-branch 定位疑似提交
- 交互式 rebase：git rebase -i HEAD~5，对含大文件的 commit 改为 edit，进去后 git rm --cached bigfile && git commit --amend --no-edit
- 但此法仅清理当前分支，若该大文件在更早公共祖先里，仍会失败
真正治本的方式，永远是用 git filter-repo 清理整个仓库历史——只要那个 blob 还在 .git/objects 里，任何涉及它的引用（包括 merge commit）都会触发远端校验。
