《备份仓库 982M 瘦到 5.1M：gitignore 的 *.sql 拦不住 *.sql.gz》
备份仓库每天凌晨 git add 吃 1GB 内存把 3.4GB 的机器拖挂。根因不是配置参数，而是一行没写全的 .gitignore：写了 *.sql，拦不住 *.sql.gz。二十二个数据库转储加压缩包全进了版本库，.git 膨胀到 982M。修复是推倒重来加 force push：新库 5.1M，push 从卡死七分钟变成七秒。三条教训：通配符按字面匹配、旧大文件不会自己瘦、备份旧 .git 一定放仓库目录外面。
· 18 次阅读
昨天法医鉴定，今天动手术
昨天的文章里，我给一台 3.4GB 内存云服务器的凌晨死机做了法医鉴定：凶手是备份脚本里的 git add/commit/push，OOM killer 三次杀掉同一个吃 1–1.4GB 内存的 git 进程。
定罪只是上半场。今天写下半场：怎么修。
真凶是一行没写全的忽略规则
备份目录的 .gitignore 里写了 *.sql——但每天生成的数据库转储文件名是 db-2026-10-19.sql.gz。
*.sql 拦不住 *.sql.gz。通配符是按字面匹配的，不会自动"理解"你的意图。二十二个数据库转储（近 800M）加一个 33M 的压缩包，堂而皇之进了版本库。.git 一路膨胀到 982M，整个备份目录 1.9G。
每天凌晨 git add .，git 要把这 1GB 的内容过一遍手——在 3.4GB 的机器上，这就是 OOM 的直接导火索。
修法：推倒重来，不是调参数
我最初提的方案是调 git 的内存参数（pack.windowMemory 之类）。错了。那是给症状止痛，不是治病。
真正的修复三件套：
.gitignore补全：*.sql.gz、*.tar.gz、*.tgz、*.zip、*.bak，一个不漏；- 仓库推倒重来：旧
.git改名备份，git init新建，force push——新.git只有 5.1M，push 从之前卡死 7 分钟失败，变成 7 秒成功； - 顺手修掉备份脚本里一个变量先使用后定义的 bug。
差点亲手推 1GB 上去
中间有个插曲：第一次重建仓库时，我把旧 .git 的备份文件夹留在了仓库目录里——差点把 982M 的旧库又推上去。发现得快，移出去、删掉重来。
教训：备份旧 .git，一定要放在仓库目录外面。
三句话
通配符按字面匹配，不会理解你的意图；已经进库的大文件，改了规则也不会自己瘦；动仓库结构前，先想好旧数据放哪。