Git仓库大小异常膨胀：增长远快于提交补丁总大小

问题原因分析 #

1. 初始大文件的固定占用
   你初始提交中添加的5个10~100MB文本文件是仓库的基础体积来源（初始仓库.git文件夹400MB即由此构成）。Git对未修改的文件仅存储一次原始Blob对象，但如果这些文件内容重复度极低，Git的Delta压缩无法对其进一步优化，体积会一直保留。

2. 提交对象的非预期膨胀
   虽然单个提交的补丁仅10~100KB，但Git存储的内容远不止补丁：每个提交会生成Commit对象、Tree对象，以及修改文件的新Blob对象。导致体积异常增长的核心可能是：

   • 文件元数据变更：即使大文件内容未修改，若提交过程中文件权限、换行符（如autocrlf自动转换）发生变更，Git会认为文件已修改，生成新的Blob对象，累积后大幅增加体积。
   • Delta压缩未生效：若你的Git版本较旧，对大体积文本文件的Delta压缩支持有限，即使仅修改少量行，也可能存储完整的文件新版本而非增量差异，导致Blob对象体积远超补丁大小。
   • 打包优化不足：尽管你执行了git gc --aggressive，若未调整打包参数（如压缩深度、窗口大小），Git可能未对所有对象进行最优的增量压缩，导致pack文件体积偏大。

管控与降低仓库大小的方法 #

1. 移除历史中的大文件（最有效） #

使用git filter-repo彻底清理初始提交中的大文件，重构仓库历史：

git filter-repo --path <大文件路径> --invert-paths

注意：此操作会改写整个仓库历史，需告知所有协作成员重新克隆仓库，且原远程仓库需强制推送覆盖。

2. 优化Git压缩配置 #

调整打包参数提升Delta压缩效率：

# 增大Delta压缩深度和窗口，提升增量压缩效果
git config pack.deltaDepth 50
git config pack.window 100
git config pack.windowMemory 1g
# 执行激进重新打包
git repack -a -d --depth=50 --window=100

3. 修复文件元数据问题 #

避免因元数据变更生成不必要的Blob对象：

# 关闭自动换行符转换
git config core.autocrlf false
# 忽略文件权限变更
git config core.filemode false
# 重置工作区并重新清理
git reset --hard
git gc --aggressive --prune=now

4. 日常维护规范 #

• 定期执行git gc --auto，让Git自动清理冗余对象、优化打包。
• 禁止将大体积文本文件（或任何非必要大文件）存入Git，此类文件应使用专门的存储服务管理，同时添加到.gitignore避免误提交。

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