远程分支本身不占空间，真正占用空间的是其历史引用的共享git对象；git ls-remote不返回大小因仅获取ref映射而不传输对象；需先fetch再用git-memory分析本地对象图以评估各远程分支的历史体积贡献。
Git 本身不记录、也不暴露“远程分支的存储空间”——因为远程分支只是服务器上一个指向某次提交的引用（refs/heads/feature-x），它本身几乎不占空间；真正占空间的是那些被该分支（及其历史）所引用的 Git 对象（blob、tree、commit），而这些对象都存放在整个仓库的 .git/objects 中，是所有分支共享的。
为什么 git ls-remote --heads origin 不返回大小信息
这个命令只读取远程仓库的 ref 列表，走的是 Git 的 upload-pack 协议，本质是获取 SHA-1 和 ref 名称的映射，比如：
8a3b2c1 refs/heads/main d4e5f6g refs/heads/dev
它不触发对象传输，也不解析对象内容，所以不可能知道某个分支“占多少 MB”。想靠这个命令查空间，注定失败。
真正要查的是“哪些提交/文件拖累了整个仓库体积”
远程分支没体积，但它的提交历史可能引入了大文件、重复 blob 或未清理的旧版本。你需要分析的是本地克隆后的完整仓库（含所有对象），再反推哪些分支长期持有这些胖对象。
- 先运行
git fetch --all --prune，确保本地远程跟踪分支（如origin/main）和远程一致 - 再用
git-memory按分支统计：它会遍历每个远程跟踪分支的 tip 提交，计算其可达对象的总 unpacked 大小（即工作区视角下“如果 checkout 这个分支，会拉下多少实际内容”） - 注意：同一 blob 被多个分支引用时，
git-memory默认按“首次出现”归因，或可选--shared模式显示共享比例
git-memory 查远程分支空间占用的实操要点
它不是直接连远程服务器查，而是基于你本地已 fetch 的数据做离线分析，所以结果依赖 fetch 的完整性。
- 安装后运行：
git-memory branch --remote origin，列出所有origin/*分支的空间占用排名 - 加
-n 5只看前 5 名，快速定位“最胖”的远程分支 - 若某分支显示体积异常大（比如几百 MB），用
git-memory commit -b origin/feature-blob-heavy进一步下钻，找到引入大文件的具体提交 - ⚠️ 坑：如果你从没
git fetch origin过某个分支，git-memory就看不到它——它只分析本地存在的remotes/origin/xxx引用
远程分支本身没有“体积”概念，所谓“远程分支空间”其实是它所承载的历史对整个对象数据库的贡献度。查的时候别被名字带偏，重点始终在本地 fetch 后的对象图分析上。
