# リポジトリの制限

リポジトリの制限事項について説明します。

特定の種類のリポジトリ リソースは非常に大きくなる可能性があり、 GitHubに過剰な処理が必要です。 そのため、リクエストが妥当な時間で終わるように、制限が設けられています。 推奨される上限を超えると、リポジトリの正常性が低下するリスクが高まります。これには、基本的な Git 操作の応答時間と UI 待機時間が遅くなることが含まれますが、これに限定されません。

> \[!NOTE] これらのガイドラインに従うとリポジトリの安定性が向上する可能性がありますが、他の要因によって予期しない動作が発生する可能性があるため、サポート可能性は保証されません。

以下の制限のほとんどは、 GitHub と API の両方に影響します。

## リポジトリのサイズ

最適なパフォーマンスと管理容易性を確保するために、リポジトリの構造とサイズに関する次の上限を超えないようにすることをお勧めします。

* **ディスク上のサイズ**: 10 GB

  ディスク上のサイズは、`.git` フォルダー (リポジトリの圧縮形式) のサイズを指します。 大規模なリポジトリではフェッチ操作が遅くなり、開発者と CI のクローン時間が長くなる可能性があります。 リポジトリ サイズを管理するには:

  * バイナリ ファイルには Git 大容量ファイルストレージ (Git LFS) を使用します。
  * プログラムによって生成されたファイルを Git の外部 (オブジェクト ストレージなど) に格納します。

* **ディレクトリの幅 (1 つのディレクトリ内のエントリの数)**: 3,000

  頻繁に変更されるファイルが多数含まれるディレクトリでは、リポジトリのメンテナンス コストが大幅に増加し、基本的な Git 操作のパフォーマンスが低下する可能性があります。 ファイルを浅いディレクトリ構造にセグメント化すると、これらのツリーのサイズが小さくなり、作成される新しいデータが少なくなります。

* **ディレクトリの深さ**: 50

  ディレクトリ ツリーが深いと、履歴のウォーキング操作が遅くなる可能性があります。

* **ブランチの数**: 5,000

  多数のブランチが存在すると、フェッチ操作で不要なデータが発生し、その結果、転送速度が遅くなったり、極端な場合にはリポジトリのパフォーマンスが制限されたりすることがあります。

## アクティビティ

調整とパフォーマンスの問題を回避するには、次の運用制限内に留まることをお勧めします。

* **プッシュ サイズ**: この制限は 2 GB で適用されます。

* **単一オブジェクトのサイズ**:

  推奨される上限は 1 MB です。 これは 100 MB で適用されます。 Git リポジトリ内の大きなファイルを追跡するには、 Git LFSを使用することをお勧めします。 「[Git Large File Storageについて](/ja/enterprise-server@3.22/repositories/working-with-files/managing-large-files/about-git-large-file-storage)」を参照してください。

* **Git の読み取り操作 (フェッチやクローンなど)**:

  推奨される上限は、リポジトリあたり毎秒 15 操作です。 大量の読み取り操作が行われると、リポジトリのパフォーマンスが制限されることがあります。 CI、マシン ユーザー、サード パーティ アプリケーションなどの自動化されたプロセスでは、場合によってはリポジトリのパフォーマンスが低下する可能性があります。 CI のクローン戦略を最適化するか、リポジトリ キャッシュ サーバーを使用することを検討してください。 浅いクローンでは完全なクローンよりもサーバーのコストと負荷が少なくなり、パフォーマンスが向上する可能性があることに注意してください。

* **プッシュ レート**: 推奨される上限は、リポジトリごとに毎分 6 回のプッシュです。

## テキストの制限

GitHub には、Markdown 図や人魚図など、一部のファイルの書式設定されたプレビューが表示されます。
GitHub ファイルが小さい (通常は 2 MB 未満) 場合は、常にこれらのプレビューをレンダリングしようとしますが、より複雑なファイルがタイムアウトし、プレーン テキストにフォールバックするか、まったく表示されない可能性があります。 これらのファイルは、常に生の形式で使用できます。例えば `HOSTNAME/user/repo/raw`、`https://HOSTNAME/user/repo/raw/octocat/Spoon-Knife/main/index.html` を介して提供します。 ファイルの raw URL を取得するには、 **\[Raw]** ボタンをクリックします。

## 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 に分割する必要があります。

## 組織とアカウントの制限

組織とアカウントは、**100,000** リポジトリを超えることはできません。 アカウントが **50,000** リポジトリを超えると、上限に近づいていることを知らせるバナーが表示されます。 さらに、管理者には電子メール通知が届き、監査ログは作成された追加の 5,000 個のリポジトリごとに更新されます。 「[リポジトリについて](/ja/enterprise-server@3.22/repositories/creating-and-managing-repositories/about-repositories#about-repository-ownership)」を参照してください。

## 統合と GitHub Apps

GitHubで統合を構築する場合は、ユーザーが生成したデータをアカウントで一元化するのではなく、独自のGitHub アカウントに格納します。 これにより、ユーザーは作業を完全に管理できるようになり、またリポジトリの制限を超えないようにするのに役立ちます。