{"meta":{"title":"2 GiB プッシュ制限のトラブルシューティング","intro":"2 GiB プッシュ制限を回避する方法について説明します。","product":"概要","breadcrumbs":[{"href":"/ja/get-started","title":"概要"},{"href":"/ja/get-started/using-git","title":"Git の使用"},{"href":"/ja/get-started/using-git/troubleshooting-the-2-gb-push-limit","title":"プッシュの最大制限"}],"documentType":"article"},"body":"# 2 GiB プッシュ制限のトラブルシューティング\n\n2 GiB プッシュ制限を回避する方法について説明します。\n\n## プッシュ制限について\n\nGitHub には、1 回のプッシュで最大 2 GiB の制限があります。 非常に大きなリポジトリを初めてアップロードしようとしたり、他のプラットフォームから大きなリポジトリをインポートしたり、大規模な既存リポジトリの履歴を書き換えようとしたときに、この制限に達する可能性があります。\n\nこの制限に達すると、次のいずれかのエラー メッセージが表示される場合があります。\n\n* `fatal: the remote end hung up unexpectedly`\n* `remote: fatal: pack exceeds maximum allowed size`\n\nプッシュをより小さな部分に分割するか、Git 履歴を削除した後最初からやり直して対処します。 2 GiB を超える 1 つのコミットを行い、Git 履歴を削除して最初から開始できない場合は、対話型のリベースを実行して、大きなコミットを複数の小さなコミットに分割する必要があります。\n\n## 大きなプッシュを分割する\n\nプッシュを小さな部分に分割することで、制限に達しないようにすることができます。それぞれのサイズは 2 GiB 未満にする必要があります。 ブランチがこのサイズ制限内にある場合は、一度にまとめてプッシュできます。 ただし、ブランチが 2 GiB を超える場合は、プッシュをさらに小さな部分に分割し、一度に数回のコミットのみをプッシュする必要があります。\n\n1. リモートをまだ構成していない場合は、リポジトリを新しいリモートとして追加します。 詳しくは、「[リモートリポジトリを管理する](/ja/get-started/git-basics/managing-remote-repositories#adding-a-remote-repository)」をご覧ください。\n\n2. ローカル リポジトリのメイン ブランチの履歴に沿って分散された適切なコミットを見つけるには、次のコマンドを実行します。\n\n   ```shell\n   git log --oneline --reverse refs/heads/BRANCH-NAME | awk 'NR % 1000 == 0'\n   ```\n\n   このコマンドは、1000 回目のコミットごとに表示されます。 数値を増やすか減らすと、ステップ サイズを調整できます。\n\n3. これらのコミットをそれぞれ、GitHub でホストされているリポジトリに一度に 1 つずつプッシュします。\n\n   ```shell\n   git push REMOTE-NAME +<YOUR_COMMIT_SHA_NUMBER>:refs/heads/BRANCH-NAME\n   ```\n\n`remote: fatal: pack exceeds maximum allowed size` メッセージ が表示された場合は、手順 2 のステップ サイズを小さくして、もう一度やり直してください。\n\n1. 手順 2 の履歴で指定したコミットごとに同じプロセスを実行します。\n2. このリポジトリを初めて GitHub にプッシュする場合は、残りの参照がすべて確実にプッシュされるように最後にミラー プッシュを実行します。\n\n   ```shell\n   git push REMOTE-NAME --mirror\n   ```\n\n   それでも大きすぎる場合は、同じ手順を実行して他のブランチを段階的にプッシュ アップする必要があります。\n\n手順に慣れてきたら、手順 2 から 4 を自動化するとプロセスを簡略化できます。 次に例を示します。\n\n```shell\nstep_commits=$(git log --oneline --reverse refs/heads/BRANCH-NAME | awk 'NR % 1000 == 0')\necho \"$step_commits\" | while read commit message; do git push REMOTE-NAME +$commit:refs/heads/BRANCH-NAME; done\n```\n\n## 最初から始める\n\nリポジトリに履歴がない場合、または最初のコミットが単独で 2 GiB を超えていて、Git 履歴をリセットしても構わない場合は、最初から開始することもできます。\n\n1. ローカル コピーで、隠し `.git` フォルダーを削除して以前のすべての Git 履歴を削除し、ファイルが詰まった通常のフォルダーに戻します。\n\n2. 新しい空のフォルダーを作成します。\n\n3. 新しいフォルダーで `git init` と `git lfs install` を実行し、新しい空の GitHub リポジトリをリモートとして追加します。\n\n4. 既に Git 大容量ファイルストレージ を使用していて、使用する予定の Git LFS 追跡ルールの一覧がすべて古いフォルダー内の `.gitattributes` ファイルに既に記載されている場合は、それを新しいフォルダーにコピーする最初のファイルにする必要があります。 Git LFS が通常の Git ストレージにコミットされるのを防ぐために、他のファイルを追加する前に、必ず追跡ルールが設定されるようにする必要があります。\n\n   Git LFS をまだ使用していない場合は、この手順をスキップするか、他のファイルをコピーする前に、新しいフォルダー内の `.gitattributes` ファイルで使用する追跡ルールを設定します。 詳しくは、「[Git Large File Storage を設定する](/ja/repositories/working-with-files/managing-large-files/configuring-git-large-file-storage)」をご覧ください。\n\n5. 2 GiB 未満のファイルのバッチを古いフォルダーから新しいフォルダーに移動します。 各バッチを移動したら、コミットを作成し、次のバッチを移動する前にプッシュします。 慎重なアプローチを取り、約 2 GiB にこだわることができます。 または、Git LFS 用のファイルを含むフォルダーがある場合は、バッチあたり 2 GiB の制限を考慮するときにこれらのファイルを無視できます。\n\n古いフォルダーが空になったら、GitHub リポジトリにすべてが入っているはずです。 Git LFS を使用している場合は、Git LFS 用のすべてのファイルを Git LFS ストレージにプッシュする必要があります。"}