Git で大容量ファイルのプッシュに失敗する原因と解決策：Git LFS設定から履歴削除まで徹底解説

チーム開発を進める中で、大きなバイナリファイルを含むGitリポジトリをリモート（GitHubなど）へ git push しようとした際、突如として通信エラーで失敗するトラブルは頻繁に発生します。代表的なエラーメッセージは以下の通りです：

error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

こうした問題は開発作業を停滞させ、チーム全体のリリースを阻害します。本稿では、原因の切り分けと具体的な5つの解決策を解説します。

主な原因分析

1. ホスティングサービスの容量制限

GitHubやGitLabなどの主要プラットフォームは、単一ファイルのサイズや1回のプッシュ容量に明確な上限を設けています：

• GitHub：単一ファイルの上限は100MB（50MB超過で警告）
• GitLab：デフォルト上限は10MB（サーバー設定により変更可）
• Gitee：単一ファイルの上限は通常50MB

2. ネットワーク通信とバッファの制約

• HTTP/HTTPS経由のPOSTバッファ容量不足によるタイムアウト
• 不安定なネットワーク環境下でのパケット損失
• クライアント端末側のメモリ不足による圧縮処理の失敗

3. Git自体のアーキテクチャ設計

Gitは本来、ソースコード（テキストの行単位の差分）を追跡するために最適化されています。大容量のバイナリファイルをコミットすると、差分ではなくファイル全体がオブジェクトとしてリポジトリに保存され、.git ディレクトリが肥大化してしまいます。

実践的な解決策

解決策1：Git LFS（Large File Storage）の導入【推奨】

Git LFSは、大容量バイナリファイルをGit本体から切り離して外部ストレージで管理する公式の拡張機能です。

インストールと設定手順：

# 1. Git LFS の初期設定
git lfs install

# 2. 追跡対象のファイル拡張子を指定
git lfs track "*.psd"
git lfs track "*.zip"
git lfs track "*.mp4"
git lfs track "*.pdf"

# 3. 追跡ルールの確認
git lfs track

# 4. .gitattributes をコミット
git add .gitattributes
git add .
git commit -m "feat: 大容量ファイル管理にGit LFSを導入"

# 5. 通常通りプッシュ
git push origin main

適したファイル：動画素材、Photoshopデータ、機械学習モデル、アーカイブファイルなど。

解決策2：Git の HTTP バッファサイズを拡張する

ネットワーク通信のバッファ溢れが原因の場合、ローカルのGitバッファサイズを引き上げることで解消できます：

# グローバルのPOSTバッファを500MBに設定（バイト単位）
git config --global http.postBuffer 524288000

# 対象リポジトリのみに設定する場合
git config http.postBuffer 524288000

# 圧縮率を最大に設定
git config --global core.compression 9

# 再度プッシュを試行
git push

解決策3：コミット履歴から大容量ファイルを完全に削除する

すでにローカルで大きなファイルをコミットしてしまっている場合、単に .gitignore に追加しただけでは解決しません。Gitの過去のコミットツリーから該当ファイルを完全に抹消する必要があります：

# 方法A：BFG Repo-Cleaner を使用（推奨・高速）
java -jar bfg.jar --strip-blobs-bigger-than 100M your-repo.git

# 方法B：git filter-branch を使用
git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch path/to/large-file.bin' \
  --prune-empty --tag-name-filter cat -- --all

# 履歴修正後の強制プッシュ（共有リポジトリでは注意）
git push --force --all
git push --force --tags

解決策4：大容量ファイルを分割する

LFSを使用せず、一時的に大きな圧縮ファイルをプッシュしたい場合は、コマンドラインで100MB未満に分割します：

# 100MB単位で分割
split -b 100m large-file.zip large-file-part.

# 分割ファイルをコミット
git add large-file-part.*
git commit -m "feat: 分割されたアーカイブ資産を追加"
git push

解決策5：外部オブジェクトストレージの活用

そもそもソースコード以外の重い素材はGitで管理せず、外部サービスへ切り出すのが定石です：

• AWS S3 / Cloudflare R2：静的Webアセットや映像データ
• Google Drive / Dropbox：社内共有のドキュメントやデザイン原本
• npm / Artifactory：ビルド成果物やパッケージ依存関係

予防策：Pre-commit フックによる事前検知

誤って巨大なファイルをコミットしないよう、.git/hooks/pre-commit に自動チェックを仕込んでおくと安心です：

#!/bin/sh
max_size=52428800 # 50MB

for file in $(git diff --cached --name-only); do
  if [ -f "$file" ]; then
    size=$(ls -l "$file" | awk '{print $5}')
    if [ "$size" -gt "$max_size" ]; then
      echo "エラー: $file が50MBの上限を超えています。"
      echo "Git LFSを使用するか、ファイルを削除してください。"
      exit 1
    fi
  fi
done

まとめ

Gitの大容量ファイルプッシュエラーは、状況に応じた適切なアプローチが肝要です。恒久的なバイナリ管理には「Git LFS」、一時的な通信エラーには「バッファ調整」を適用し、健全で軽量なリポジトリ運用を維持しましょう。