git ls-remote --size 仅对注解标签有效，显示其对象本身大小（几十字节），对分支无效且无输出；它不反映分支内容体积，也不能用于估算远程分支大小。
Git 本身不直接提供“远程分支大小”的查询能力，git ls-remote 只返回引用（SHA）和名称，不包含对象体积；所谓“分支大小”本质是该分支可达的所有提交、树、blob 对象的总存储开销——必须在本地有对应对象或克隆后才能估算。直接查远程仓库的精确分支大小不可行，但有几种实用替代路径。
用 git ls-remote --size 看的是什么？
这个命令实际**不生效**：git ls-remote 的 --size 选项仅对 refs/tags/ 下带注解标签（annotated tag）的引用有效，且显示的是 tag 对象本身的大小（几十字节），不是分支内容。对 refs/heads/ 分支完全无输出，别被名字误导。
常见错误现象：git ls-remote --size origin main 返回空或仅 SHA，没有任何尺寸信息。
真正能用的只有：
-
git ls-remote origin—— 列出所有远程引用及其 SHA - 配合后续本地分析（见下一条）
用 git rev-list --objects 估算分支对象体积
这是最贴近“分支大小”含义的本地估算方式：计算某一分支可到达的所有 Git 对象（不含重复）的原始体积总和。
操作步骤：
- 先确保该分支已 fetch：
git fetch origin main - 运行：
git rev-list --objects origin/main | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize)' | awk '$1 == "blob" {sum += $3} END {print sum/1024/1024 " MB"}' - 若要包含 tree/commit 对象（更完整但偏高估），去掉
$1 == "blob"过滤
注意：该结果不含 pack 压缩率，比实际 .git/objects/pack/ 占用高 2–5 倍；它反映的是“未压缩原始数据量”，适合横向比较分支间差异。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
用 git-sizer 查看远程仓库整体结构
想知远程仓库“为什么大”，git-sizer 是目前最可靠的工具——但它需要你先 git clone --bare 远程仓库（只下载 .git，无工作区）。
实操建议：
- 克隆为裸仓库：
git clone --bare https://github.com/user/repo.git repo.git - 进入目录：
cd repo.git - 运行：
git-sizer -v—— 输出含 “largest trees”, “largest blobs”, “commits per branch” 等维度
关键输出字段：
-
total size of tracked files：所有被 track 的文件原始体积总和 -
total size of loose objects：松散对象大小（提示是否该git gc） -
largest commit/largest blob：定位膨胀源
它不按分支切分大小，但能告诉你哪些提交/文件拖累了整个仓库，这才是优化的起点。
为什么不能跳过克隆直接查远程分支大小？
Git 协议设计上不暴露对象体积元数据。远程服务器（如 GitHub/GitLab）只响应 upload-pack 请求，发送的是 delta-compressed packfile 流，客户端无法提前得知其中每个分支贡献了多少字节。
所以所有“查远程分支大小”的需求，最终都得落回到本地分析——要么浅克隆 + rev-list 快速估算，要么裸克隆 + git-sizer 深度诊断。没有捷径，也没有魔法命令。
最容易被忽略的一点：很多人试图用 du -sh .git 当作“分支大小”，其实那是整个仓库的磁盘占用，包括所有分支、reflog、stash、未 push 提交等杂项——它不等于任何单一分支的体积，也不代表 push 时会传多少数据。
