Sparrow项目Git仓库瘦身实践：从800MB到7MB的优化之路

在软件开发过程中，Git仓库的体积膨胀是一个常见但容易被忽视的问题。本文将以Sparrow项目为例，深入探讨如何通过Git历史清理技术，将一个包含大量历史数据的仓库从800MB优化到仅7MB，同时保持项目完整性。

问题背景

Sparrow作为一个长期开发的项目，在迭代过程中不可避免地积累了大量历史数据。特别是早期版本中包含了大量文档图片（JPG/PDF）和模型数据文件，这些文件虽然在后来的提交中被移除，但仍然保留在Git历史记录中，导致克隆时需要下载近800MB的数据包。

通过分析发现：

• .git/objects/pack目录占用了799MB空间
• 历史记录中包含大量已删除的文档目录（sparrow-data/donut/docs）
• 最大单文件达到5.98MB（研究用的Jupyter Notebook）

技术分析

Git仓库体积膨胀的主要原因包括：

1. 大文件历史遗留：即使后续提交中删除了大文件，Git仍保留这些文件的引用
2. 频繁重构：项目结构调整导致路径变更，Git会保留所有版本的文件路径
3. 开发中间产物：研究阶段的临时文件（如.ipynb）被意外提交

优化方案

1. 使用git filter-repo工具

git filter-repo是Git官方推荐的仓库清理工具，相比传统的BFG工具，它提供了更精确的分析和控制能力。通过分析可以清楚地看到：

git filter-repo --analyze

分析结果显示：

• 已删除但仍占空间的目录：sparrow-data/donut/docs（1.67GB）
• 主要大文件类型：.jpg（5.2GB）、.pdf（968MB）
• 具体大文件路径：研究用Notebook文件（6.2MB）

2. 执行清理操作

基于分析结果，可以针对性地清理特定路径和文件类型：

git filter-repo --path sparrow-data/donut/ --invert-paths
git filter-repo --path-glob '*.jpg' --invert-paths
git filter-repo --path-glob '*.pdf' --invert-paths

3. 验证清理效果

使用git-sizer工具验证清理效果：

git-sizer -v

清理后关键指标变化：

• 总文件大小：从2.18GB降至MB级别
• 最大文件大小：从5.98MB降至KB级别
• 仓库克隆时间：从几分钟降至几秒钟

最佳实践建议

1. 定期清理：建议每个主要版本发布后进行仓库清理
2. 使用.gitignore：提前排除不需要版本控制的文件类型
3. 分离大文件：考虑使用Git LFS管理二进制大文件
4. 提交前检查：使用pre-commit钩子检查文件大小

结语

通过本次优化，Sparrow项目的Git仓库体积从800MB降至7MB，显著提升了开发者的克隆和协作效率。这一案例也提醒我们，良好的版本控制习惯和定期的仓库维护同样重要。对于长期维护的项目，建议将仓库清理纳入常规维护流程，保持代码库的健康状态。