最終更新: 2026-06-29

Git リポジトリのクローンサイズ

git のフルクローンサイズとは、git clone を実行したときに転送されるデータの総量です。ワーキングツリー（最新スナップショット）と、.git/objects に格納されたオブジェクトヒストリの両方を含みます。CI/CD パイプラインのビルド時間やオンプレミスのストレージ計画に大きく影響するため、事前に概算しておく意義があります。

推定モデルと計算式

git はコミット間の差分をデルタ符号化し、まとめて zlib 圧縮したパックファイルに格納します。ここで採用するヒューリスティックモデルは次のとおりです。

$N$ はリポジトリの総コミット数、$C$ は圧縮前の 1 コミットあたり平均変更量、$r$ はパック圧縮率（0〜1 の実数）、$W$ はワーキングツリーサイズ、$H$ が推定ヒストリサイズ、$T$ が推定フルクローンサイズです。

計算例： コミット数 2,000 件、1コミットあたりの平均変更量 30 kB、圧縮率 30%、ワーキングツリー 150 MB のリポジトリを想定します。

フルクローンの転送量は約 168 MB と見積もられます。

各パラメータの調べ方

パラメータを実際のリポジトリから計測するには、以下のコマンドが参考になります。

• ワーキングツリーサイズ: du -sh . --exclude=.git でディレクトリ全体のサイズを確認します。
• コミット数: git rev-list --count HEAD で総コミット数を取得します。
• 1コミットあたりの平均変更量: git log --stat の出力からおおまかな傾向を把握できます。より精確に集計したい場合は git log --numstat を利用したスクリプトが便利です。
• パック圧縮率: git count-objects -vH を実行し、size-pack と size の比率から逆算できます。コードリポジトリでは 20〜40%、バイナリファイルを多く含む場合は 80〜100% 近くになります。

ヒストリサイズが大きくなる仕組み

git は追記型のデータ構造を採用しており、コミットするたびに差分オブジェクトが積み重なります。ファイルを頻繁に編集するほどオブジェクト数が増え、パックファイルのサイズも大きくなります。長命なリポジトリでは、ヒストリが最新スナップショットを数倍上回ることも珍しくありません。

git repack -a -d による再パックや git gc による不要オブジェクトの削除を定期的に実施することで、パックファイルの断片化を抑え、実際のオンディスクサイズを削減できます。

シャロークローンによる転送量の削減

CI パイプラインやデプロイスクリプトで完全な履歴が不要な場合、シャロークローンを使うと転送量を大幅に減らせます。

git clone --depth 1 <url>

--depth 1 は先端スナップショットのみを取得するため、ダウンロード量はワーキングツリーサイズにわずかなオブジェクトを加えた程度に収まります。コミット数が多い古いリポジトリでは、フルクローンと比べて転送量が 90% 以上削減されることもあります。

シャロークローンでは git log の参照範囲が制限されます。後から完全な履歴が必要になった場合は git fetch --unshallow で補完できます。

モデルの限界

このモデルは、全コミットのデルタサイズと圧縮率が一様であると仮定したヒューリスティックです。実際のサイズは次の要因によって変わります。

• デルタチェーンの深さや参照先オブジェクトの分布
• 大容量バイナリファイルの有無（画像・動画・機械学習モデルなど）
• git lfs（Git Large File Storage）の使用有無
• core.compression や pack.compression などの git 設定

正確なオンディスクサイズを確認するには git count-objects -vH を実行してください。

関連する計算

パックファイルや転送後のサイズ削減率を評価するには、圧縮率の計算 の計算を参照してください。ネットワーク経由でのクローン所要時間を概算するには、データ転送時間の計算 の計算を利用してください。