説明：「Not enough disk space to clone the repository」は何を意味するのか。約9GBの事例から、容量の確認方法、軽い取得方法、やってはいけない対処を整理する。
「リポジトリをコピーするための空き容量が足りません」。
このエラーを見た瞬間、最初に思うのは「え、コード壊れた？」だろう。でも違う。これはソースコードの実行エラーではなく、作業場所にコピーするための容量が足りないという通知だ。
そして調べたら、あるリポジトリについてGitHubが報告する大きさが約9GBだった。
9GB。記事の原稿をちょっと取りたいだけなのに、引っ越し業者を呼ぶ量。「ファイルを1つ編集したい」という依頼に対して、なぜか倉庫ごとトラックに積み込もうとしている。
エラーが教えていること、教えていないこと
典型的な表示は「Not enough disk space to clone the repository」。つまり、GitHub上のデータを作業環境に複製する段階で、利用可能なディスク容量が不足したという意味だ。
これだけで「GitHub上のファイルが消えた」「リポジトリが壊れた」とは言えない。反対に、エラー文だけでは実際の空き容量、ダウンロード量、履歴と現行ファイルのどちらが重いかも分からない。
約9GBという数字は、あるリポジトリに対してGitHubのAPIが返したサイズ情報を丸めたもの。手元のクローンが必ず9GBになるという実測ではない。展開したファイルや作業用の一時領域で、必要な容量は変わる。
なぜそんなに大きくなる？
Gitは現在のファイルだけでなく、変更の履歴も管理する。以前入れた大きな画像、生成ファイル、バックアップなどが履歴に残っていれば、今のフォルダーが小さく見えても取得が重くなる場合がある。
さらに記事、翻訳、画像、出力ファイルを次々に追加する運用なら、現行ファイルの総量自体も増える。原因は現行ファイルかもしれないし、過去の履歴かもしれない。どちらが主犯かはファイル容量と履歴を調べて判定する。
GitHub公式は、管理しやすいリポジトリを小さく保つことを推奨し、ディスク上の大きさに10GBという推奨上限を示している。ただし、これは「10GBに達した瞬間にクローンが禁止される」という一律の判定ではない。また、GitHub APIのサイズ表示と、ローカルの.gitフォルダーの計測値はそのまま同一視できない。
直すなら、倉庫を全部運ばない
まずは新しい作業環境で一度やり直す。以前の作業で一時ファイルがたまっていた場合に有効だ。ただし、元のリポジトリそのものが大きいなら、再発し得る。
ファイルを1つ読む・書くのが目的なら、GitHubのAPIで対象ファイルだけを扱う方法が速い。記事の更新に、毎回プロジェクト全体のクローンは要らない。
Gitが必要なら、履歴を浅くし、本文データを必要になるまで取得せず、展開するファイルも絞る方法がある。
git clone --depth=1 --filter=blob:none --sparse REPOSITORY_URL
これは取得量を減らすための組み合わせで、どんな環境でも成功する魔法ではない。取得後に必要なフォルダーだけ指定する運用が向いている。履歴全体を使う分析や特定のGit操作には制約も出る。
絶対に勢いでやらないこと
「容量が重いなら過去の履歴を全部消せばいいじゃん」と飛びつくのは危険。履歴の書き換えは共同作業、古いリンク、自動処理に影響する場合がある。原因を調べて、退避と影響範囲を確認してから行う作業だ。
確認する順番は、作業環境の空き容量、現在のファイル群の大きさ、Gitの履歴や大きなファイル、そして本当に全体を取得する必要があるか、の順が分かりやすい。
結局、壊れていたのはコードではなく前提だった
欲しかったのは数行の修正。始まろうとしていたのは9GB級の引っ越し。
このエラーは「もっと容量を増やせ」というだけの話ではない。必要なファイルだけ触れる仕事に、なぜ毎回リポジトリ全部を運ぶのか？と問い直すきっかけでもある。
記事1本を追加するたびに倉庫を丸ごと輸送するなら、先に見直すべきなのはトラックの大きさより運び方だ。
参考： GitHubのリポジトリ推奨値 ・ 大きなファイルの扱い ・ Git clone公式文書
