ある種のリポジトリ リソースは非常に大きくなる可能性があり、GitHub で過大な処理が必要になる場合があります。 そのため、リクエストが妥当な時間で終わるように、制限が設けられています。 推奨される上限を超えると、リポジトリの正常性が低下するリスクが高まります。これには、基本的な Git 操作の応答時間と UI 待機時間が遅くなることが含まれますが、これに限定されません。
メモ
これらのガイドラインに従うとリポジトリの安定性が向上する可能性がありますが、他の要因によって予期しない動作が発生する可能性があるため、サポート可能性は保証されません。
以下の制限の多くは GitHub と API の両方に影響します。
リポジトリのサイズ
最適なパフォーマンスと管理容易性を確保するために、リポジトリの構造とサイズに関する次の上限を超えないようにすることをお勧めします。
-
ディスク上のサイズ: 10 GB
ディスク上のサイズは、
.gitフォルダー (リポジトリの圧縮形式) のサイズを指します。 大規模なリポジトリではフェッチ操作が遅くなり、開発者と CI のクローン時間が長くなる可能性があります。 リポジトリ サイズを管理するには:- バイナリ ファイルの場合は Git Large File Storage (Git LFS) を使用します。
- プログラムによって生成されたファイルを Git の外部 (オブジェクト ストレージなど) に格納します。
-
ディレクトリの幅 (1 つのディレクトリ内のエントリの数): 3,000
頻繁に変更されるファイルが多数含まれるディレクトリでは、リポジトリのメンテナンス コストが大幅に増加し、基本的な Git 操作のパフォーマンスが低下する可能性があります。 ファイルを浅いディレクトリ構造にセグメント化すると、これらのツリーのサイズが小さくなり、作成される新しいデータが少なくなります。
-
ディレクトリの深さ: 50
ディレクトリ ツリーが深いと、履歴のウォーキング操作が遅くなる可能性があります。
-
ブランチの数: 5,000
多くのブランチを使用するとフェッチ操作で不要なデータが発生するため、転送時間が遅くなり、極端な場合にはリポジトリのパフォーマンスの調整が起きることがあります。
アクティビティ
調整とパフォーマンスの問題を回避するには、次の運用制限内に留まることをお勧めします。
-
プッシュ サイズ: この制限は 2 GB で適用されます。
-
単一オブジェクトのサイズ:
推奨される上限は 1 MB です。 これは 100 MB で適用されます。 Git リポジトリで大きなファイルを追跡するには、Git LFS を使うことをお勧めします。 「Git Large File Storageについて」を参照してください。
-
Git の読み取り操作 (フェッチやクローンなど):
推奨される上限は、リポジトリあたり毎秒 15 操作です。 大量の読み取り操作により、リポジトリのパフォーマンスが調整されることがあります。 CI、マシン ユーザー、サード パーティ アプリケーションなどの自動化されたプロセスでは、場合によってはリポジトリのパフォーマンスが低下する可能性があります。 CI のクローン戦略を最適化するか、リポジトリ キャッシュ サーバーを使用することを検討してください。 浅いクローンでは完全なクローンよりもサーバーのコストと負荷が少なくなり、パフォーマンスが向上する可能性があることに注意してください。
-
プッシュ レート: 推奨される上限は、リポジトリごとに毎分 6 回のプッシュです。
テキストの制限
GitHub には、マークダウン図や人魚図など、一部のファイルの書式設定されたプレビューを表示します。 GitHub は、ファイルが小さい (通常は 2 MB 未満) 場合は常にこれらのプレビューのレンダリングを試みますが、より複雑なファイルがタイムアウトし、プレーン テキストにフォールバックするか、まったく表示されないことがあります。 これらのファイルは、常に生の形式で使用できます。例えば https://HOSTNAME/user/repo/raw/octocat/Spoon-Knife/master/index.html、HOSTNAME/user/repo/raw を介して提供します。 ファイルの raw URL を取得するには、 [Raw] ボタンをクリックします。
Pull request の上限
Pull request アクティビティが多いリポジトリの遅延とパフォーマンスの問題を減らすには、次の制限内に留まることをお勧めします。
-
(同じブランチに対して) 開いている pull request: 1,000
同じブランチをターゲットとして多くの pull request が開いていると、マージ可能性チェックが遅くなり、タイムアウトが発生する可能性があります。 マージ キューを使用している場合は、[require this branch to be up to date before merging] 設定を無効にすることを検討してください。 これにより、キュー内の pull request に対してのみマージ可能性チェックが制限されます。
-
Pull request のマージ レート: 1 分あたり 1 個のマージされた pull request
各マージによって、開いているすべての pull request のマージ可能性チェックがトリガーされます。これにより、特にビジー状態のリポジトリでパフォーマンスのボトルネックが発生する可能性があります。 これにより、マージの競合状態が発生し、開発者の生産性に影響を与える可能性もあります。 負荷を下げるために、マージ キューを使用している場合は、[require this branch to be up to date before merging] 設定を無効にします。
diff の制限
diff はきわめて大きくなることがあるため、コミット、プルリクエスト、比較ビューには制限が設けられています。
- プル要求では、 読み込むことができる合計差分が 20,000 行 を超えたり、生の差分データ が 1 MB を超えたりすることはできません。
- 1 つのファイルの差分が 、読み込むことができる 20,000 行 を超えたり、生の差分データ が 500 KB を超えたりすることはできません。 1 つのファイルに対して _400 行_と 20 KB が自動的に読み込まれます。
- 1 つの差分内のファイルの最大数は 300 に制限されます。
- 1 つの diff あたりでレンダリング可能なファイル (画像、PDF、GeoJSON ファイルなど) の最大数は、25 に制限されています。
制限された diff の一部が表示される場合もありますが、制限を超える部分は表示されません。
コミット リストの制限
比較ビューと pull request のページには、base と head リビジョン間のコミットのリストが表示されます。 これらのリストではコミットの数は 250 に制限されています。 その制限を超える場合は、追加のコミットがあるという注意書きが表示されます (コミット自体は表示されません)。
[コミット] タブに表示されるコミットの最大数は 10,000 です。 必要に応じて、git rev-list --count mybranch などの他のツールを使用し、大量のコミットをカウントおよび列挙します。
リベースの制限
[Rebase and merge] オプションを使った pull request のマージは、100 コミットに制限されています。 コミットが 100 を超える pull request がある場合は、マージ コミットを作成するか、squash してマージするか、コミットを複数の pull request に分割する必要があります。
Organization とアカウントの制限
Organization とアカウントは、100,000 リポジトリを超えることはできません。 アカウントが 50,000 リポジトリを超えると、上限に近づいていることを知らせるバナーが表示されます。 さらに、管理者には電子メール通知が届き、監査ログは作成された追加の 5,000 個のリポジトリごとに更新されます。 「リポジトリについて」を参照してください。
統合と GitHub Apps
GitHub で統合を構築する場合は、ユーザーが生成したデータを、自分のアカウントで一元化するのではなく、それぞれ独自の GitHub アカウントに格納します。 これにより、ユーザーは作業を完全に管理できるようになり、またリポジトリの制限を超えないようにするのに役立ちます。