1. 当Git仓库变成胖子我们遇到了什么问题第一次发现Git仓库出问题是在某个周一的早晨。CI/CD流水线突然报错Jenkins控制台里赫然显示着git clone failed的红色警告。我尝试调整clone深度、延长超时时间甚至换了台服务器重试结果都一样——这个曾经乖巧的仓库现在像个任性的孩子死活不肯被完整克隆。用du -sh .git命令查看本地仓库大小后我吓了一跳一个原本应该以代码为主的工程.git目录竟然占用了近10GB空间进一步分析发现罪魁祸首是那些被频繁修改的二进制文件——设计同事上传的PSD源文件、Unity场景资源、编译后的.so/.dll文件它们就像仓库里的垃圾食品每次修改都会产生全新的副本导致仓库体积呈指数级增长。这让我想起之前遇到过的一个极端案例某图形化编程项目用图片格式存储源代码单个文件就超过50MB开发团队每天提交几十次变更结果不到三个月就把Git服务器硬盘撑爆了。Git的设计初衷是高效管理文本文件差异比较和压缩都很容易但对二进制文件却显得力不从心——它会把整个文件重新存储而不是只记录变化部分。2. Git LFS给二进制文件开个外挂仓库Git LFSLarge File Storage就像是给Git装了个外挂硬盘。它的核心原理很巧妙用轻量的文本指针代替实际的二进制文件存储在Git仓库里。这些指针看起来像这样version https://git-lfs.github.com/spec/v1 oid sha256:9171c8350d72ccca6ad60ac80b577157ad1f9fd44ca05744216e02ccbfcdf491 size 10260当执行git clone时默认只会下载这些指针文件。真正需要用到二进制内容时比如checkout到某个分支LFS会自动从专用服务器下载对应的文件。整个过程对开发者基本透明日常的git pull/push等操作都不需要改变习惯。我特别喜欢LFS的这几个设计智能缓存下载过的文件会缓存在本地切换分支时不用重复下载按需加载可以只下载当前分支需要的文件不像传统Git必须全量克隆版本控制依然保留完整的修改历史只是存储方式更高效3. 迁移前的战前准备决定迁移后我列了个检查清单备份备份备份用git bundle create repo.bundle --all创建完整仓库快照并上传到安全的云存储。这是最后的救命稻草。团队沟通在群里发了迁移公告约定两小时的维护窗口。特别提醒迁移期间禁止推送代码迁移后所有成员需要重新克隆仓库本地未提交的改动要先stash或备份环境检查确保所有开发机和CI服务器都安装了Git LFS客户端。可以用这个命令测试git lfs env | grep git-lfs/如果没安装各平台的安装方法如下Ubuntu/Debian:sudo apt install git-lfsCentOS/RHEL:sudo yum install git-lfsMacOS:brew install git-lfs服务端配置如果是自建GitLab需要管理员在/etc/gitlab/gitlab.rb中添加gitlab_rails[lfs_enabled] true然后执行gitlab-ctl reconfigure。云端Git服务如GitHub/GitLab.com默认已开启。4. 实战迁移五步瘦身计划4.1 第一步识别肥胖元凶先用这个命令找出仓库里的大文件git rev-list --objects --all \ | git cat-file --batch-check%(objecttype) %(objectname) %(objectsize) %(rest) \ | awk /^blob/ {print substr($0,6)} \ | sort --numeric-sort --key2 \ | cut -c 1-12,41- \ | $(command -v gnumfmt || echo numfmt) --field2 --toiec-i --suffixB --padding7 --roundnearest输出结果类似5c2d3e1b1a8 4.0MiB path/to/bigfile.psd a1b2c3d4e5f 12MiB assets/texture.png4.2 第二步创建迁移策略根据扫描结果我决定迁移这些类型的文件图片*.psd, *.png, *.jpg压缩包*.zip, *.tar.gz编译产物*.so, *.dll, *.a数据集*.bin, *.data对应的.gitattributes模板*.psd filterlfs difflfs mergelfs -text *.png filterlfs difflfs mergelfs -text *.zip filterlfs difflfs mergelfs -text4.3 第三步重写历史这是最关键的步骤使用git lfs migrate命令git lfs migrate import --include*.psd,*.png,*.zip,*.so,*.dll --everything这个过程可能会很耗时我们的仓库用了约45分钟。如果中断了可以用--skip-fetch参数继续。4.4 第四步验证迁移结果检查哪些文件已被LFS管理git lfs ls-files确认.gitattributes文件是否自动生成git show HEAD:.gitattributes4.5 第五步强制推送git push --force --all git push --force --tags注意这步会重写所有分支的历史确保团队其他成员都已知晓5. 迁移后的维护与优化5.1 团队成员如何适配对于已经存在的本地仓库最简单的处理方式是rm -rf /path/to/repo git clone gitexample.com:repo.git如果有未提交的修改可以git checkout -b old-master-backup git branch -D master git fetch origin git checkout master # 然后cherry-pick需要的提交5.2 清理本地缓存迁移者的本地仓库需要执行git lfs pull git reflog expire --expire-unreachablenow --all git gc --prunenow5.3 CI/CD配置调整在Jenkins等CI系统中需要安装Git LFS插件在构建步骤中添加git lfs install --skip-repo git lfs pull6. 效果对比数字会说话我们统计了迁移前后的关键指标指标迁移前迁移后变化率仓库大小(.git)9.8GB420MB-95.7%完整克隆时间32分钟2分钟-93.8%浅克隆(深度1)时间18分钟45秒-95.8%日常提交速度8-12秒1-2秒-85%分支切换速度15-20秒3-5秒-75%特别惊喜的是CI流水线的平均执行时间从原来的52分钟降到了37分钟主要节省在代码拉取环节。对于频繁提交的二进制文件如UI设计稿每次提交的大小从平均50MB降到了不到1KB。7. 那些年我们踩过的坑坑1文件类型遗漏第一次迁移后发现某些.so文件没被处理。原因是文件名中有版本号如libxxx-1.2.3.so。解决方案是调整匹配模式git lfs migrate import --include*.[so],*.dll --everything坑2权限问题自建GitLab服务器出现LFS上传失败原因是nginx配置缺少client_max_body_size 500m;坑3本地缓存爆炸LFS默认缓存路径在~/.git/lfs/objects可以用这个命令清理旧版本git lfs prune坑4部分文件不想迁移有些二进制文件确实需要直接存在Git里比如小图标可以在.gitattributes中添加*.ico binary8. 进阶技巧让LFS更高效按需下载只获取当前需要的LFS文件git lfs fetch --includeassets/textures/*.png批量迁移历史分支对于有上百个分支的仓库可以先用脚本列出所有分支git for-each-ref --format%(refname:short) refs/heads/ branches.txt然后批量迁移while read branch; do git lfs migrate import --include*.psd --branch$branch done branches.txt监控LFS使用量GitHub API可以查询LFS用量curl -s -H Authorization: token YOUR_TOKEN \ https://api.github.com/repos/owner/repo | grep -i lfs迁移后的仓库整理使用BFG工具进一步清理历史java -jar bfg.jar --convert-to-git-lfs *.psd --no-blob-protection repo.git
