目次
概要
Git clone実行時に「fatal: early EOF」「fatal: The remote end hung up unexpectedly」「fatal: index-pack failed」といったエラーが発生することがある。本記事では、このエラーの原因と5つの解決方法を環境別に詳しく解説する。
この記事で分かること
- early EOFエラーが発生する原因
- 5つの解決方法（コード例付き）
- 環境別のトラブルシューティング
- よくある質問と回答
対象読者: Git初心者〜中級者
動作確認環境: Git 2.30以降（2025年1月時点）
early EOFエラーとは
「early EOF」(End Of File) エラーは、Gitがリモートリポジトリからデータを取得する際、予期せぬタイミングで通信が切断されることで発生するエラーである。
典型的なエラーメッセージ
fatal: early EOF
fatal: The remote end hung up unexpectedly
fatal: index-pack failed
このエラーは特に大容量のリポジトリをcloneする際に発生しやすく、通信が途中で切れることで完全なデータを受信できない状態を示している。
エラーが発生する主な原因
early EOFエラーが発生する原因は主に以下の3つである。
1. リポジトリのサイズが大きすぎる
リポジトリのサイズが数GB以上ある場合、ネットワークの安定性や帯域幅の制限により、一度に全データを転送できないことがある。
リポジトリサイズ | エラー発生リスク | 推奨対処法 |
|---|---|---|
〜100MB | 低い | 通常のclone |
100MB〜1GB | 中程度 | depth指定 |
1GB以上 | 高い | depth + バッファ調整 |
2. ネットワークの不安定性
Wi-Fi環境や帯域制限がある回線では、長時間の通信が途中で切断される可能性が高まる。
3. Gitの設定値が小さい
Gitのデフォルト設定では、大容量データの転送に対応できない場合がある。特にhttp.postBufferの値が小さいと、大きなリポジトリのcloneに失敗しやすい。
解決方法1: depth指定でcloneを分割する【推奨】
最も手っ取り早く効果的な方法は、取得するコミット履歴の深さを制限して、一度に転送するデータ量を減らすことである。
手順
# ステップ1: 最新のコミットのみを取得
git clone --depth 1 <リポジトリURL>
# ステップ2: 必要に応じて履歴を追加取得
cd <リポジトリ名>
# 深さを指定して追加取得
git fetch --depth 10
# または、全ての履歴を取得
git fetch --unshallow
メリット・デメリット
メリット | デメリット |
|---|---|
✅ 最も確実に動作する | ❌ 完全な履歴が一度に取得できない |
✅ ネットワーク負荷が軽い | ❌ 複数回のコマンド実行が必要 |
✅ 初心者でも簡単 | ❌ ブランチ情報が限定される |
適用場面
- 大容量リポジトリ（1GB以上）
- ネットワークが不安定な環境
- 最新のコードだけが必要な場合
解決方法2: HTTPバッファサイズを増やす
Gitの通信バッファサイズを増やすことで、大きなデータを一度に転送できるようになる。
手順
# バッファサイズを500MBに設定
git config --global http.postBuffer 524288000
# その後、通常通りclone
git clone <リポジトリURL>
設定値の目安
リポジトリサイズ | 推奨バッファサイズ |
|---|---|
〜500MB | 100MB (104857600) |
500MB〜2GB | 500MB (524288000) |
2GB以上 | 1GB (1048576000) |
注意点
この設定はグローバルに適用されるため、不要になったら元に戻すことを推奨する。
# 設定を削除
git config --global --unset http.postBuffer
解決方法3: 圧縮を無効化する
Git はデフォルトでデータを圧縮して転送するが、これがボトルネックになる場合がある。
手順
# 圧縮を無効化してclone
git -c core.compression=0 clone <リポジトリURL>
メリット・デメリット
メリット | デメリット |
|---|---|
✅ CPUリソースを節約 | ❌ 転送データ量が増える |
✅ 低スペックマシンで有効 | ❌ 時間がかかる場合がある |
解決方法4: プロトコルを変更する（HTTPS → SSH）
HTTPSではなくSSHプロトコルを使うことで、通信の安定性が向上する場合がある。
手順
# HTTPSの場合
# https://github.com/user/repo.git
# SSHに変更
git clone git@github.com:user/repo.git
事前準備
SSH接続には公開鍵の登録が必要である。
# SSH鍵の生成
ssh-keygen -t ed25519 -C "your_email@example.com"
# 公開鍵をGitHubに登録
cat ~/.ssh/id_ed25519.pub
解決方法5: タイムアウト時間を延長する
ネットワークが遅い環境では、タイムアウト時間を延長することで成功する場合がある。
手順
# タイムアウトを10分に設定
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 600
git clone <リポジトリURL>
トラブルシューティング
それでも解決しない場合
以下の方法を順番に試してみよう。
- GitHubのミラーを使う
# GitHubの場合、GitHub CLIを使う gh repo clone user/repo - ZIPファイルでダウンロード
GitHubの場合、リポジトリページから「Code」→「Download ZIP」でダウンロード可能。履歴は含まれないが、最新のコードは取得できる。
- 別のネットワークで試す
Wi-Fiではなく有線LAN、または別のネットワーク環境で試すとうまくいく場合がある。
Windows固有の問題
Windowsでは、パスの長さ制限により同様のエラーが発生することがある。
# 長いパス名を有効化
git config --system core.longpaths true
よくある質問（FAQ）
Q1: depth 1 でcloneした後、特定のブランチを取得するには？
git fetchで特定のブランチを指定して取得できる。
git fetch origin <ブランチ名>:<ブランチ名>
git checkout <ブランチ名>
Q2: 全ての解決方法を試しても失敗する場合は？
リポジトリの管理者に問い合わせることを推奨する。サーバー側の設定や一時的な障害の可能性がある。
Q3: depth指定でcloneすると、どのくらいデータ量が減る？
プロジェクトによるが、履歴が長いリポジトリでは90%以上削減できることもある。例えば、10年の履歴がある5GBのリポジトリが、depth 1では500MB程度になる場合がある。
Q4: 企業のプロキシ環境下で失敗する場合は？
プロキシ設定を追加する必要がある。
git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy http://proxy.example.com:8080
まとめ
Git clone時の「early EOF」エラーは、主にリポジトリのサイズが大きい場合やネットワークが不安定な場合に発生する。解決方法として、以下の5つを紹介した。
- depth指定でcloneを分割（最も推奨）
- HTTPバッファサイズを増やす
- 圧縮を無効化
- プロトコルをSSHに変更
- タイムアウト時間を延長
まずは「解決方法1」のdepth指定を試し、それでも解決しない場合は他の方法を組み合わせて試すことを推奨する。多くの場合、depth指定とバッファサイズの調整で解決できるはずである。