簡介：遇到「Not enough disk space to clone the repository」該怎麼辦？從約 9GB 的實例，弄清楚空間不足的原因與較省空間的做法。
只是想改幾行字，工具卻表示無法複製儲存庫，因為磁碟空間不足。
這不代表程式碼壞掉。問題發生在接收副本的工作環境，也不等於 GitHub 上的檔案消失了。
有個案例中，GitHub API 回報的儲存庫大小約為 9GB。明明只需要一份文件，系統卻準備把整座倉庫搬來。叫一杯飲料，結果連飲料店的冰箱都送到了。
錯誤訊息能告訴我們多少？
它指出複製工作遇到容量不足，但無法單憑這句話得知剩餘空間、已下載的資料量，或是現有檔案與歷史紀錄哪一邊比較肥。
約 9GB 是 GitHub API 回報數值的概數，不是失敗環境中實際複製量的測量結果。下載資料、展開的檔案與暫存空間所占容量可能不同。
倉庫怎麼會長這麼大？
Git 除了目前的檔案，也保留版本歷史。以前提交的大圖、備份和自動產生的檔案，可能仍留在歷史資料中。若持續增加文章、多語譯文、圖片與輸出結果，目前的檔案也可能真的不少。
要分開檢查的是現有檔案與歷史資料。不做盤點，就無法確定哪個才是主因。
GitHub 官方提出包含 .git 目錄在磁碟上建議上限 10GB 的管理指引。這並非到達 10GB 就必然禁止複製的硬性開關，API 顯示值也未必等於本機 .git 的大小。
有需要才搬，不要整倉打包
若舊工作環境累積太多暫存檔，重新建立環境可能解決問題；但若儲存庫本身龐大，也可能再次遇到相同錯誤。
只要讀寫單一檔案，可以在權限允許時使用 GitHub 的檔案 API。需要使用 Git 時，可以嘗試：
git clone --depth=1 --filter=blob:none --sparse REPOSITORY_URL
它限制取得的歷史深度、延後下載檔案內容，也縮小一開始展開的範圍。不過它不是必勝指令，某些需要完整歷史的操作會受限制。
別急著把歷史清空
改寫或刪除歷史可能影響其他開發者、原有參照與自動化。先查看剩餘空間、目前的大檔案與歷史中的大物件；要進行破壞性清理前，務必備份並評估影響。
真正該修的是搬運方式
原本的需求是修改幾行文字，執行方式卻變成搬運 9GB 等級的倉庫。
只改一份檔案，為什麼每次都得搬整座倉庫？ 有時候最該升級的不是硬碟，而是工作流程。
