GitHub仓库会存满，因单个仓库上限100GB且LFS配额受限；需用du -sh .git查体积，BFG或filter-repo清理历史大文件，LFS托管二进制文件，并通过CI检查、归档和外部存储长期管理。
如果您发现 GitHub 仓库上传失败或提示空间不足，可能与仓库容量限制有关。GitHub 对单个仓库及账户整体存储设定了明确边界。以下是关于容量是否“会存满”的具体说明与管理操作：
一、GitHub 仓库的硬性容量限制
GitHub 官方对仓库施加了两层独立限制：单个仓库大小上限和 Git 大文件存储（Git LFS）配额。超出任一限制均会导致推送失败。
1、单个仓库总大小（含所有提交历史中的对象）不得超过 100 GB；
2、免费账户的 Git LFS 配额为每月 1 GB，存储上限为 1 GB；
3、Pro 账户的 Git LFS 配额为每月 2 GB，存储上限为 2 GB；
4、Team 和 Enterprise 账户按成员数分配 LFS 配额，但单仓库仍受 100 GB 总体积约束。
二、识别仓库实际占用体积的方法
本地克隆仓库后，其 .git 目录完整保存了所有提交对象、分支引用及历史快照，是判断真实体积的关键路径。
1、在终端中进入仓库根目录，执行命令：du -sh .git；
2、若需排除工作区文件仅统计 Git 对象，运行：git count-objects -vH；
3、使用 git rev-list --all --objects | sort -k 2 > all-objects.txt 导出全部对象列表；
4、结合 git ls-tree -r --long HEAD | grep '\.zip\|\.pdf\|\.iso' 筛查大文件路径。
三、清理仓库历史中大文件的三种方式
当 .git 目录膨胀主因是误提交的大文件时，需从历史中彻底移除其二进制对象，而非仅删除工作区文件。
1、使用 BFG Repo-Cleaner 工具：下载 JAR 文件后执行 java -jar bfg.jar --delete-files '*.log' my-repo.git；
2、使用 git filter-repo：安装后运行 git filter-repo --path-glob '*.mp4' --invert-paths；
3、手动重写历史：执行 git filter-branch --tree-filter 'rm -f path/to/bigfile.zip' --prune-empty HEAD，随后强制推送。
四、将大文件迁移至 Git LFS 的标准流程
Git LFS 将大文件内容替换为轻量文本指针，使仓库主历史保持精简，同时保留文件可追溯性。
1、在仓库根目录运行 git lfs install 初始化 LFS 支持；
2、执行 git lfs track "*.psd" 声明需托管的文件类型；
3、提交 .gitattributes 文件：git add .gitattributes && git commit -m "track PSD files via LFS"；
4、重新添加并推送大文件：git add design.psd && git push origin main。
五、长期容量管理的三项实践措施
避免反复触发清理操作，需建立可持续的提交规范与归档机制，从源头控制体积增长。
1、在 CI 流水线中加入体积检查步骤：用 git ls-tree -r --long HEAD | awk '$3 > 50*1024*1024 {print $4}' 报告超 50MB 文件；
2、为文档类仓库单独创建 docs/ 子目录，并通过 gh-pages 分支托管静态页面，不混入源码历史；
3、对测试数据集等非代码资产，改用 GitHub Releases 附加文件或外部对象存储（如 S3），并在 README 中提供下载链接。
