核心是重写提交历史以物理删除大文件blob对象，git-filter-repo适合精准路径清理，BFG适合按大小批量清除，二者均需备份、强制推送并通知协作者重新克隆。
要彻底物理擦除 Git 历史中误提交的数十兆大文件，核心是重写整个提交历史，让这些文件的 blob 对象从 .git/objects 中被真正删除（而非仅从工作区或最新提交中移除）。git-filter-repo 和 BFG Repo-Cleaner 都能做到这点，但操作逻辑、适用场景和安全性略有不同。下面分步骤说明关键实操要点。
一、先定位问题文件，避免盲目清理
不查清“谁在占空间”，直接开刀容易误伤。运行以下命令快速找出历史中最大的前 10 个 blob：
bashgit rev-list --objects --all | while read hash path; do size=$(git cat-file -s "$hash" 2>/dev/null); echo "$size $hash $path"; done | sort -n | tail -10
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
重点关注：
• *.mp4、*.zip、*.tar、*.dump 等二进制/归档文件
• dist/、build/、node_modules/、public/uploads/ 等目录路径
• 文件大小是否稳定在 10MB–200MB 区间（正好是“数十兆”的典型范围）
二、用 git-filter-repo 精准剔除指定文件或目录
适合已知路径、需保留其余历史结构、且希望操作可追溯的场景。注意：它会重写所有 commit hash，所以必须备份并通知协作者。
- 进入项目根目录后，不要直接在带远程 origin 的普通仓库里执行；推荐先创建裸镜像备份：
git clone --mirror your-repo-url.git repo-backupcd repo-backup - 删单个文件（如
large-video.mp4）：git filter-repo --path large-video.mp4 --invert-paths --force - 删整个目录（如
docs/assets/）：git filter-repo --path docs/assets/ --invert-paths --force - 批量删多个路径（新建
remove-list.txt，每行一个路径）：git filter-repo --paths-from-file remove-list.txt --invert-paths --force
三、用 BFG Repo-Cleaner 快速按大小批量清除
适合不知道具体路径、但确认存在大量“几十兆级”冗余文件的场景。BFG 不依赖 Python，纯 Java 运行，速度通常比 filter-repo 更快，尤其对超大仓库。
- 下载并准备工具（以 Linux/macOS 为例）：
git clone https://gitcode.com/gh_mirrors/bf/bfg-repo-cleanercd bfg-repo-cleaner && java -jar bfg.jar --version - 对镜像仓库执行清理（例如删所有 >30MB 的文件）：
java -jar bfg.jar --strip-blobs-bigger-than 30M my-repo.git - 也可只删最大的 N 个文件（更可控）：
java -jar bfg.jar --strip-biggest-blobs 5 my-repo.git - 清理后必须执行强制压缩：
cd my-repo.git && git reflog expire --expire=now --all && git gc --prune=now --aggressive
四、清理后必须做的收尾动作
无论用哪个工具，以下三步缺一不可，否则文件仍可能残留或无法推送：
-
验证体积是否真实下降：回到项目根目录，运行
du -sh .git（macOS/Linux）或Get-ChildItem .git -Recurse | Measure-Object -Property Length -Sum（PowerShell），对比清理前后大小 -
强制推送到远程（覆盖旧历史）：
git push --force --all origingit push --force --tags origin -
通知所有协作者重新克隆：他们不能再用旧本地仓库继续工作，必须
git clone新地址，否则会出现引用错乱、重复提交等问题
