正如林纳斯·托尔斯泰所说：“幸福的 Git 仓库都是相似的，不幸的 Git 仓库各有各的不幸。”

Git-Sizer 就是一个帮助我们发现 Git 仓库潜在问题的强大工具。它能够计算本地 Git 仓库的各种规模指标，并标记出那些可能导致问题或不便的指标。

为什么需要 Git-Sizer？

理想情况下，Git 仓库应该小于 1 GiB，超过 5 GiB 时，仓库就会变得难以处理。大型仓库的克隆和重新打包需要很长时间，并且会占用大量磁盘空间。

Git-Sizer 可以帮助我们识别以下具体问题：

1. 仓库总体过大
2. 仓库引用（分支/标签）过多
3. 仓库对象过多
4. 仓库中包含特大 blob（文件）
5. 仓库中包含许多大型文本文件的版本
6. 仓库中包含特大 tree（目录）
7. 仓库在单个提交中包含重复的文件
8. 仓库中包含过长的路径名
9. 仓库中存在其他异常情况（如长链的标注标签、具有数十个父提交的合并等）

通过识别这些问题，可以采取措施来优化仓库的大小和结构，提高 Git 的性能。

Git-Sizer 的安装方法

前提条件

确保你已经安装了 Git 命令行客户端（版本 >= 2.6）。注意：git-sizer 会调用 git 命令来检查仓库的内容，因此运行 git-sizer 时，git 命令必须在你的 PATH 中。

安装选项

1. 使用预编译版本（推荐）
   • 访问 GitHub releases page 下载对应平台的 ZIP 文件
   • 解压文件
   • 将可执行文件（git-sizer 或 git-sizer.exe）移动到系统 PATH 目录下
2. 从源码构建
   • 参考项目文档中的 docs/BUILDING.md 进行构建安装

如何使用 git-sizer？Git-Sizer 的使用方法

基本使用

进入要分析的 Git 仓库完整（非浅层）克隆的目录，运行：

不需要任何选项。你可以通过输入 git-sizer -h 或继续阅读来了解可用的选项。

专业提示

如果你将 git-sizer 添加到 PATH 中，可以通过两种方式运行：

1. 直接运行 git-sizer
2. 使用 Git 子命令形式 git sizer

使用 Git 子命令形式的好处是可以在中间添加 Git 选项，例如：

git -C /path/to/my/repo sizer

如果没有将 git-sizer 添加到 PATH 中，需要使用完整路径：

常用选项

• --verbose: 显示所有统计信息
• --threshold=<value>: 设置关注度阈值
• --critical: 仅显示严重问题（相当于 –threshold=30）
• --json: 输出机器可读的 JSON 格式
• --json-version=1 或 --json-version=2: 选择旧式或新式 JSON 输出
• --names=none: 不显示对象引用信息

Git-Sizer 的输出解读

默认情况下，git-sizer 以表格格式输出其结果。例如，使用 --verbose 选项以便输出所有统计信息：

输出结果示例：

Processing blobs: 1652370
Processing trees: 3396199
Processing commits: 722647
Matching commits to trees: 722647
Processing annotated tags: 534
Processing references: 539
| Name                        | Value    | Level of concern |
| --------------------------- | -------- | ---------------- |
| Overall repository size     |          |                  |
| * Commits                   |          |                  |
| * Count                     | 723 k    | *                |
| * Total size                | 525 MiB  | **               |
| * Trees                     |          |                  |
| * Count                     | 3.40 M   | **               |
| * Total size                | 9.00 GiB | ****             |
| * Total tree entries        | 264 M    | *****            |
| * Blobs                     |          |                  |
| * Count                     | 1.65 M   | *                |
| * Total size                | 55.8 GiB | *****            |
| * Annotated tags            |          |                  |
| * Count                     | 534      |                  |
| * References                |          |                  |
| * Count                     | 539      |                  |
|                             |          |                  |
| Biggest objects             |          |                  |
| * Commits                   |          |                  |
| * Maximum size [2]          | 72.7 KiB | *                |
| * Maximum parents [3]       | 66       | ******           |
| * Trees                     |          |                  |
| * Maximum entries [4]       | 1.68 k   | *                |
| * Blobs                     |          |                  |
| * Maximum size [5]          | 13.5 MiB | *                |
|                             |          |                  |
| History structure           |          |                  |
| * Maximum history depth     | 136 k    |                  |
| * Maximum tag depth [6]     | 1        |                  |
|                             |          |                  |
| Biggest checkouts           |          |                  |
| * Number of directories [7] | 4.38 k   | **               |
| * Maximum path depth [8]    | 13       | *                |
| * Maximum path length [9]   | 134 B    | *                |
| * Number of files [10]      | 62.3 k   | *                |
| * Total size of files [10]  | 747 MiB  |                  |
| * Number of symlinks [11]   | 40       |                  |
| * Number of submodules      | 0        |                  |
[2] 91cc53b0c78596a73fa708cceb7313e7168bb146
[3] 2cde51fbd0f310c8a2c5f977e665c0ac3945b46d
[4] 4f86eed5893207aca2c2da86b35b38f2e1ec1fc8 (refs/heads/master:arch/arm/boot/dts)
[5] a02b6794337286bc12c907c33d5d75537c240bd0 (refs/heads/master:drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h)
[6] 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c (refs/tags/v2.6.11)
[7] 1459754b9d9acc2ffac8525bed6691e15913c6e2 (589b754df3f37ca0a1f96fccde7f91c59266f38a^{tree})
[8] 78a269635e76ed927e17d7883f2d90313570fdbc (dae09011115133666e47c35673c0564b0a702db7^{tree})
[9] ce5f2e31d3bdc1186041fdfd27a5ac96e728f2c5 (refs/heads/master^{tree})
[10] 532bdadc08402b7a72a4b45a2e02e5c710b7d626 (e9ef1fe312b533592e39cddc1327463c30b0ed8d^{tree})
[11] f29a5ea76884ac37e1197bef1941f62fda3f7b99 (f5308d1b83eba20e69df5e0926ba7257c8dd9074^{tree})

输出结果是一个表格，显示了测量的指标、其数值以及对哪些值可能值得关注的粗略指示。在所有情况下，只包含从引用可访问的对象（即不包括不可访问的对象，也不包括只能从引用日志访问的对象）。

Git-Sizer 的输出采用表格格式，包含三列：

1. Name（指标名称）

显示测量的具体指标

2. Value（数值）

显示指标的具体数值，使用如下单位：

• 计数：k（千）、M（百万）、G（十亿）等
• 大小：B（字节）、KiB（1024 字节）、MiB（1024 KiB）等

3. Level of concern（关注度）

使用星号（*）表示与"典型"Git 仓库相比的异常程度：

• 星号越多，表示潜在问题越严重
• 感叹号（!）表示极高的值（相当于 30 个以上的星号）

主要统计部分

1. 整体仓库大小（Overall repository size）
   • Commits：提交数量和总大小
   • Trees：树对象数量和总大小
   • Blobs：文件对象数量和总大小
   • Tags：标签数量
   • References：引用数量
2. 最大对象（Biggest objects）
   • 最大提交大小
   • 最大树条目数
   • 最大文件大小
3. 历史结构（History structure）
   • 最大历史深度
   • 最大标签深度
4. 最大检出（Biggest checkouts）
   • 目录数量
   • 最大路径深度
   • 最大路径长度
   • 文件数量和总大小

常见问题解决方案

1. 仓库过大

• 避免存储生成的文件（编译输出、JAR 文件等）
• 使用 Git-LFS 存储大型媒体文件
• 避免存储压缩文件（ZIP、tar 等）

2. 引用过多

• 删除不需要的标签和分支
• 避免推送远程跟踪分支
• 考虑使用 git notes 代替标签
• 将不常用的标签和分支存储在单独的 fork 中

3. 目录结构问题

• 避免在单个目录中放置超过几千个文件
• 使用多层次目录结构来分散文件
• 控制路径长度在合理范围内

最佳实践

1. 定期运行 Git-Sizer 检查仓库状态
2. 关注"Level of concern"列中的警告标记
3. 对于高关注度的问题及时处理
4. 在项目早期就建立良好的仓库管理习惯
5. 结合项目具体情况确定可接受的阈值

总结

Git-Sizer 是一个强大的仓库分析工具，能够帮助我们及早发现并解决 Git 仓库中的规模相关问题。通过定期使用 Git-Sizer 进行检查，我们可以确保仓库保持在健康的状态，提高开发效率。虽然 Linux 内核这样的大型项目可能会突破一些常规限制，但只要保持合理的结构，Git 仍然可以有效地管理它们。