简介：“Not enough disk space to clone the repository”到底是什么意思？结合一个约 9GB 的案例，讲清原因、轻量获取方式和危险操作。
只想改几行文字，工具却弹出提示：克隆仓库的磁盘空间不够。
第一反应可能是：代码坏了？其实这说的是接收副本的工作环境没有足够空间，不是程序运行报错，也不代表 GitHub 上的源文件丢失。
曾有一个仓库，GitHub API 报告的大小约为 9GB。只想取一份文档，却仿佛连仓库大楼都要搬过来。买瓶水，结果给你送来整座超市。
这条报错能说明什么？
它能说明复制工作遇到了空间不足。它不能告诉你剩余空间的准确数字、已经下载多少数据，以及真正占空间的是当前文件还是历史记录。
约 9GB 是 GitHub API 返回的仓库大小的近似值，并非失败环境中克隆副本的实际测量值。下载的数据、展开后的文件和临时空间，可能有不同的大小。
为什么仓库会这么大？
Git 除了保存当前文件，还管理历史版本。过去提交的大图片、备份或自动生成的文件，可能继续增加历史数据量。持续增加文章、译文、图片和构建产物，也可能让当前目录本身变大。
所以要分别调查当前文件与历史对象。只看文件名猜谁是罪魁祸首，容易抓错人。
GitHub 官方给出了仓库健康方面的建议，包括磁盘上 .git 目录大小建议不超过 10GB。它不是“达到 10GB 就一定禁止克隆”的硬开关，也不能与 API 的大小字段直接画等号。
别为一个文件搬整座仓库
如果旧工作环境堆满了临时文件，换一个全新的环境可能有用；如果仓库本身巨大，同样的错误仍可能出现。
只需读取或修改某个文件时，可以在权限允许的情况下通过 GitHub 文件 API 操作。需要 Git 时，可以尝试减少历史和初始文件下载：
git clone --depth=1 --filter=blob:none --sparse REPOSITORY_URL
这会减少历史获取、按需下载文件内容，并缩小初始检出范围。但它不是万能保证，有些依赖完整历史的操作会受到限制。
千万别随手删除历史
清理历史可能影响其他人的克隆、旧引用及自动化流程。先检查剩余磁盘空间、当前大文件与历史中的大对象，再制定清理方案；有破坏性的操作之前要备份。
最后的问题
需求只有一句：“修改这个文件。”执行方式却是：“把 9GB 级别的仓库搬走。”
真正值得问的是：既然只改一个文件，为什么每次都要搬整座仓库？ 比起一味加大硬盘，先改运输方式，往往更直接。
