嘿，我之前也碰到过一模一样的问题！其实Push成功只是说明当前工作区和最新提交里没有大文件，但GitHub Pages构建时会扫描整个仓库的所有历史提交对象，只要历史里藏着超过限制的文件，就会触发报错。另外还有缓存、部署分支的坑，给你一步步拆解：

可能的原因 #

• 历史提交残留大文件：你用的git filter-branch有时候会漏处理——比如其他分支的提交、标签里的记录，或者某些深层的历史快照里还留着那个124MB的文件。GitHub Pages的容量检测会遍历所有Git对象，哪怕文件早就被删除，只要历史里存在就会触发限制。
• Pages构建缓存没清：GitHub Pages会缓存之前的构建产物，有时候仓库内容更新了，缓存还抱着旧文件不放，导致检测误判。
• 部署分支没同步清理：如果你的Pages是从gh-pages分支部署的（而非主分支），那你只清理主分支的话，gh-pages分支里的大文件还在，自然会报错。

针对性解决步骤 #

1. 彻底清理所有历史中的大文件（推荐用官方工具） #

git filter-branch已经被GitHub标记为过时了，推荐用更可靠的git filter-repo来彻底移除大文件的所有痕迹：

• 先安装git filter-repo（用包管理器就行，比如Mac上brew install git-filter-repo，Windows或者Linux可以用pip安装）
• 执行命令彻底抹掉目标文件的所有历史：

  git filter-repo --path FILENAME --invert-paths
  

• 强制推送到所有分支和标签（注意：这会重写仓库历史，如果有协作的小伙伴，一定要提前告诉他们重新克隆仓库，不然他们的本地仓库会和远程冲突）：

  git push origin --force --all
  git push origin --force --tags
  

2. 清理Pages的构建缓存 #

有时候缓存是罪魁祸首，手动清一下就好：

• 打开你的GitHub仓库页面，点击顶部的「Settings」
• 左侧菜单找到「Pages」
• 在「Build and deployment」区域，找到「Clear cache」按钮点击清理，然后随便提交一个空commit触发重新构建：

  git commit --allow-empty -m "Trigger Pages rebuild"
  git push
  

3. 检查并清理部署分支 #

如果你的Pages不是从主分支部署的，比如用的gh-pages：

• 切换到部署分支：

  git checkout gh-pages
  

• 重复步骤1的git filter-repo命令清理该分支的历史，然后强制推送：

  git push origin gh-pages --force
  

4. 确认.gitignore配置真的生效 #

别忘确认.gitignore的规则没写错，而且文件已经完全从Git缓存中移除：

git rm --cached FILENAME
git add .gitignore
git commit -m "Remove FILENAME from cache and add to .gitignore"
git push

按照这些步骤来，基本就能解决Pages的容量报错问题啦！

内容的提问来源于stack exchange，提问作者jini