GitHub での大きいファイルについて

GitHub Enterprise Cloud でのサイズ制限について

GitHub Enterprise Cloud では、すべての Git リポジトリへの十分なストレージの提供に努めていますが、ファイル とリポジトリの。 ユーザーに対してパフォーマンスと信頼性を確保するため、リポジトリ全体の正常性のシグナルを積極的に監視しています。 リポジトリの正常性は、サイズ、コミットの頻度、コンテンツ、構造など、さまざまな要因が互いに及ぼす作用です。

ファイル サイズ制限

GitHub Enterprise Cloud には、リポジトリで許可されるファイルのサイズに制限があります。 50 MiBより大きいファイルを追加または更新しようとすると、Gitから警告が表示されます。 変更は引き続きリポジトリに正常にプッシュされますが、パフォーマンスへの影響を最小限に抑えるためにコミットを削除することを検討してもよいでしょう。 詳細については、「ファイルをリポジトリの履歴から削除する」を参照してください。

GitHub Enterprise Cloud は 100 MiB を超えるファイルをブロックします。

この制限を超えるファイルを追跡するには、Git Large File Storage (Git LFS) を使う必要があります。 詳しくは、「Git Large File Storageについて」をご覧ください。

リポジトリ内で大きなファイルを配布する必要がある場合は、ファイルを追跡するのではなく、GitHub.com でリリースを作成できます。 詳細については、「大きなバイナリを配布する」を参照してください。

Git は、大きい SQL ファイルを処理するようには設計されていません。 大きいデータベースを他の開発者と共有するには、ファイル共有サービスを使うことをお勧めします。

リポジトリ サイズの制限

リポジトリは小さく保ち、理想としては 1GB 未満、および 5GB 未満にすることを強くお勧めします。 リポジトリが小さいほど、クローン作成が速く、操作やメンテナンスが簡単になります。 リポジトリがインフラストラクチャに過度に影響する場合は、GitHub Support から是正措置を求めるメールが送られてくる場合があります。 特に多くのコラボレータが参加している大規模なプロジェクトでは、柔軟に対応するよう努めており、可能な限り解決策を見つけるために協力します。 リポジトリのサイズと全体的な健全性を効果的に管理することで、リポジトリがインフラストラクチャに影響を与えることを防ぎます。 github/git-sizer リポジトリには、リポジトリ分析のためのアドバイスとツールがあります。

外部依存関係によって、Git リポジトリが非常に大きくなる場合があります。 リポジトリが外部依存関係で埋まってしまうことを避けるために、パッケージマネージャーの使用をお勧めします。 一般的な言語で人気のあるパッケージ マネージャーには、Bundler、Node のパッケージ マネージャー、Maven などがあります。 これらのパッケージマネージャーは Git リポジトリの直接使用をサポートしているため、事前にパッケージ化されたソースは必要ありません。

Git はバックアップツールとして機能するようには設計されていません。 ただし、Arq、Carbonite、CrashPlan など、バックアップを実行するために特別に設計された多くのソリューションがあります。

ファイルをリポジトリの履歴から削除する

プッシュされていない直近のコミットで追加されたファイルを削除する

直近のコミットで追加されたファイルを GitHub.com にプッシュしていない場合は、ファイルを削除してコミットを修正することができます。

1. [ターミナル][ターミナル][Git Bash] を開きます。

2. ワーキングディレクトリをローカルのリポジトリに変更します。

3. ファイルを削除するには、「git rm --cached」と入力します。

   $ git rm --cached GIANT_FILE
   # Stage our giant file for removal, but leave it on disk
   

4. --amend -CHEAD を使って、この変更をコミットします。

   $ git commit --amend -CHEAD
   # Amend the previous commit with your change
   # Simply making a new commit won't work, as you need
   # to remove the file from the unpushed history as well
   

5. コミットを GitHub.com にプッシュします。

   $ git push
   # Push our rewritten, smaller commit
   

以前のコミットで追加されたファイルを削除する

以前のコミットでファイルを追加した場合は、リポジトリの履歴から削除する必要があります。 リポジトリの履歴からファイルを削除するには、git filter-repo コマンドをお勧めします。 詳しくは、「リポジトリからの機微なデータの削除」をご覧ください。

または、追加のツールをインストールしたくない場合は、対話型リベースを使って問題のあるコミットを削除することもできます。 手順は次のとおりです。

• 問題のファイルを追加または変更したコミットを把握する必要があります。
• コミットは 1 つのブランチのみに属している必要があります。
• コミットが属する 1 つのブランチでは、コミットが適用された後にマージが行われていない必要があります。

対話型リベースの詳細については、「コマンドラインで Git リベースを使う」を参照してください。 対話型リベースを使って修正するために必要な条件を満たしているかどうかが不明な場合は、git filter-repo を使うことをお勧めします。

大きなバイナリを配布する

リポジトリ内で大きなファイルを配布する必要がある場合は、GitHub.com でリリースを作成できます。 リリースでは、他の人が使用できるように、ソフトウェア、リリースノート、バイナリファイルへのリンクをパッケージ化できます。 詳細については、「リリースについて」を参照してください。

リリース内のバイナリファイルの合計サイズや、それらの配布に使用される帯域は制限されません。 ただし、個々のファイルは2 GiB未満でなければなりません。