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