アカウントと制限の設定

GitLab管理者はインスタンスでのプロジェクトとアカウントの制限を設定できます。次に例を示します:

• ユーザーが作成できるプロジェクトの数
• 添付ファイル、プッシュ、およびリポジトリのサイズ制限
• セッションの継続時間と有効期限
• アクセストークンの設定（有効期限やプレフィックスなど）
• ユーザーのプライバシーと削除の設定
• 組織およびトップレベルグループの作成ルール

デフォルトのプロジェクトの制限

新しいユーザーがパーソナルネームスペースに作成できるプロジェクトのデフォルトの最大数を設定できます。この制限は、設定を変更した後に作成された新しいユーザーアカウントにのみ影響します。この設定が既存のユーザーにさかのぼって適用されることはありませんが、既存のユーザーのプロジェクト制限は個別に編集できます。

新しいユーザーのパーソナルネームスペース内のプロジェクトの最大数を設定するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. デフォルトのプロジェクトの制限の値を増減させます。

デフォルトのプロジェクトの制限を0に設定すると、ユーザーは自分のパーソナルネームスペースではプロジェクトを作成できなくなります。ただし、グループ内でのプロジェクトの作成は引き続き可能です。

ユーザーのプロジェクト制限

特定のユーザーを編集して、そのユーザーがパーソナルネームスペースに作成できるプロジェクトの最大数を変更できます:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 概要 > ユーザーを選択します。
3. ユーザーのリストからユーザーを選択します。
4. 編集を選択します。
5. プロジェクト制限の値を増減します。

添付ファイルの最大サイズ

GitLabのコメントと返信における添付ファイルの最大サイズは、100 MBです。添付ファイルの最大サイズを変更するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. **添付ファイルサイズの上限(MiB)**の値を変更して、サイズを増減させます。

Webサーバーに設定されている値よりも大きいサイズを選択した場合、エラーが発生することがあります。詳細については、トラブルシューティングセクションを参照してください。

GitLab.comのリポジトリサイズ制限については、アカウントと制限の設定を参照してください。

最大プッシュサイズ

インスタンスの最大プッシュサイズを変更できます:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. **最大プッシュサイズ(MiB)**の値を変更して、サイズを増減させます。

GitLab.comのプッシュサイズの制限については、アカウントと制限の設定を参照してください。

リポジトリのサイズ制限

GitLabインスタンスのリポジトリは、特にLFSを使用している場合、急速に増大する可能性があります。そのサイズは指数関数的に増加し、利用可能なストレージを急速に消費してしまうことがあります。これを防ぐために、リポジトリサイズにハード制限を設定できます。この制限は、グローバル、グループごと、プロジェクトごとに設定でき、プロジェクトごとの制限が最優先されます。

リポジトリのサイズ制限は、非公開プロジェクトと公開プロジェクトの両方に適用されます。これには、リポジトリファイルとGit LFSオブジェクト（外部オブジェクトストレージに保存されている場合も含む）が含まれますが、以下は含まれません:

• アーティファクト
• コンテナ
• パッケージ
• スニペット
• アップロード
• Wiki

リポジトリサイズに制限を設定するユースケースは多数存在します。たとえば、次のようなワークフローが考えられます:

1. チームが、アプリケーションリポジトリに大きなファイルを保存する必要があるアプリを開発しています。
2. プロジェクトでGit LFSを有効にしているものの、ストレージが大幅に増加しました。
3. 利用可能なストレージを超える前に、リポジトリごとに10 GBの制限を設定します。

GitLab Self-ManagedおよびGitLab Dedicatedでは、GitLab管理者のみがこれらの制限を設定できます。この制限を0に設定すると、制限なしを意味します。GitLab.comのリポジトリサイズ制限については、アカウントと制限の設定を参照してください。

これらの設定は次の場所にあります:

• 各プロジェクトの設定:
  1. プロジェクトのホームページから、設定 > 一般に移動します。
  2. Naming, topics, avatar（名前、トピック、アバター）セクションの**リポジトリサイズ制限(MiB)**フィールドに入力します。
  3. 変更を保存を選択します。
• 各グループの設定:
  1. グループのホームページから、設定 > 一般に移動します。
  2. 名前、表示レベルセクションの**リポジトリサイズ制限(MiB)**フィールドに入力します。
  3. 変更を保存を選択します。
• GitLabのグローバル設定:
  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > 一般を選択します。
  3. アカウントと制限セクションを展開します。
  4. **リポジトリごとのサイズ制限(MiB)**フィールドに入力します。
  5. 変更を保存を選択します。

新しいプロジェクトの最初のプッシュでは、LFSオブジェクトを含めてサイズがチェックされます。サイズの合計が許可された最大リポジトリサイズを超えると、プッシュは拒否されます。

リポジトリサイズの確認

プロジェクトが、設定されたリポジトリのサイズ制限に近づいているかどうかを確認するには、次の手順に従います:

1. ストレージ使用量を表示します。リポジトリのサイズには、GitリポジトリファイルとGit LFSオブジェクトの両方が含まれます。
2. 現在の使用量と、設定したリポジトリのサイズ制限を比較して、残りの容量を見積もります。

プロジェクトAPIを使用して、リポジトリの統計情報を取得することもできます。

リポジトリサイズを削減するには、リポジトリサイズを削減する方法を参照してください。

セッションの継続期間

デフォルトのセッションの継続時間をカスタマイズする

ユーザーがアクティビティーなしでサインインしたままでいられる時間を変更できます。

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. Session duration (minutes)（セッション時間(分)）フィールドに入力します。
   Session duration (minutes)（セッション時間(分)）を0に設定すると、GitLabインスタンスが破損します。詳細については、イシュー19469を参照してください。

5. 変更を保存を選択します。
6. 変更を反映させるため、GitLabを再起動します。
   GitLab Dedicatedの場合は、サポートチケットを送信して、インスタンスの再起動をリクエストしてください。

ログイン情報を記憶するが有効になっている場合、ユーザーのセッションは無期限にアクティブなままになります。

詳細については、サインインに使用されるCookieを参照してください。

セッションが作成日から一定時間の経過後に有効期限切れになるように設定する

デフォルトでは、セッションは無効になってから一定期間の経過後にその有効期限が切れます。代わりに、セッションが作成されてから一定期間の経過後に有効期限が切れるように設定できます。

セッションの継続時間が満了すると、次の状況でもセッションが終了し、ユーザーはサインアウトされます:

• ユーザーがセッションをまだアクティブに使用している
• ユーザーがサインイン中にログイン情報を記憶するを選択している

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. Expire session from creation date（セッションの有効期限を作成日に基づいて設定する）チェックボックスをオンにします。

セッションが終了すると、ウィンドウが表示され、ユーザーに再度サインインするように求めます。

ログイン情報を記憶するオプションを設定する

ユーザーはサインイン時にログイン情報を記憶するチェックボックスをオンにできます。そのセッションは、特定のブラウザからアクセスした場合に、無期限にアクティブなままになります。セキュリティやコンプライアンスの目的でセッションを期限切れにするには、この設定をオフにします。この設定をオフにすると、セッション時間をカスタマイズした際に指定した非アクティブ時間が経過した時点で、ユーザーのセッションが確実に期限切れになります。

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. ログイン情報を記憶するチェックボックスをオンまたはオフにして、この設定を有効または無効にします。

2FAが有効な場合にGit操作のセッション時間をカスタマイズする

GitLab管理者は、2FAが有効になっている場合に、Git操作のセッション時間（分単位）をカスタマイズできます。デフォルトは15で、1 - 10080の範囲の値を設定できます。

これらのセッションの有効期間に制限を設定するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限セクションを展開します。
4. **2FAが有効な場合のGit操作のセッション時間(分)**フィールドに入力します。
5. 変更を保存を選択します。

トップレベルグループのオーナーにサービスアカウントの作成を許可する

デフォルトでは、管理者のみがサービスアカウントを作成できます。トップレベルグループのオーナーにもサービスアカウントの作成を許可するようにGitLabを設定できます。

前提要件:

• 管理者アクセス権が必要です。

トップレベルグループのオーナーにサービスアカウントの作成を許可するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. サービスアカウントを作成で、Allow top-level group owners to create Service accounts（トップレベルグループのオーナーにサービスアカウントの作成を許可する）チェックボックスをオンにします。
5. 変更を保存を選択します。

新しいアクセストークンの有効期限を必須にする

前提要件:

• 管理者である必要があります。

すべての新しいアクセストークンに対して有効期限の設定を必須にすることができます。この設定はデフォルトで有効になっており、以下に適用されます:

• サービスアカウント以外のユーザーのパーソナルアクセストークン
• グループアクセストークン
• プロジェクトアクセストークン

サービスアカウントのパーソナルアクセストークンには、アプリケーション設定APIのservice_access_tokens_expiration_enforced設定を使用してください。

新しいアクセストークンの有効期限を必須にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. Personal / Project / Group access token expiration（パーソナル/プロジェクト/グループアクセストークンの有効期限）チェックボックスをオンにします。
5. 変更を保存を選択します。

新しいアクセストークンに有効期限を必須とする場合:

• ユーザーは、新しいアクセストークンに対して、許可されたライフタイムを超えない有効期限を設定する必要があります。
• アクセストークンの最大ライフタイムを制御するには、Limit the lifetime of access tokens（アクセストークンのライフタイムを制限する）設定を使用します。

パーソナルアクセストークンのプレフィックス

パーソナルアクセストークンのプレフィックスを指定できます。カスタムプレフィックスを使用する利点情報は、次のとおりです:

• トークンが明確になり、識別しやすくなります。
• 漏洩したトークンは、セキュリティスキャン中に容易に識別できます。
• 異なるインスタンス間でのトークンの混同のリスクを軽減します。

パーソナルアクセストークンのデフォルトプレフィックスはglpat-ですが、管理者はこれを変更できます。プロジェクトアクセストークンとグループアクセストークンも、このプレフィックスを継承します。

プレフィックスを設定する

デフォルトのグローバルプレフィックスを変更するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限セクションを展開します。
4. Personal access token prefix（パーソナルアクセストークンのプレフィックス）フィールドに入力します。
5. 変更を保存を選択します。

設定APIを使用してプレフィックスを設定することもできます。

インスタンストークンのプレフィックス

インスタンスで生成されるすべてのトークンの先頭に付加されるカスタムプレフィックスを設定できます。カスタムプレフィックスを使用する利点情報は、次のとおりです:

• トークンが明確になり、識別しやすくなります。
• 漏洩したトークンは、セキュリティスキャン中に容易に識別できます。
• 異なるインスタンス間でのトークンの混同のリスクを軽減します。

トークンのカスタムプレフィックスは、次のトークンにのみ適用されます:

• CI/CDジョブトークン。
• クラスターエージェントトークン
• デプロイトークン
• 機能フラグクライアントトークン
• フィードトークン
• 受信メールトークン
• OAuthアプリケーションシークレット
• パーソナルアクセストークン
• パイプライントリガートークン
• Runner認証トークン

前提要件:

• インスタンスへの管理者アクセス権が必要です。

カスタムトークンのプレフィックスを設定するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限セクションを展開します。
4. インスタンストークンのプレフィックスフィールドに、カスタムプレフィックスを入力します。
5. 変更を保存を選択します。

アクセストークンのライフタイムを制限する

ユーザーは必要に応じて、アクセストークンの最大ライフタイムを日単位で指定できます。これには、パーソナル 、グループ 、プロジェクトアクセストークンが含まれます。このライフタイムは必須ではなく、0より大きく次の最大値以下の任意の値を設定できます:

• デフォルトでは365日。
• buffered_token_expiration_limit機能フラグを有効にした場合、400日。この拡張された制限は、GitLab Dedicatedでは利用できません。

この設定を空白のままにした場合、アクセストークンのデフォルトの許容ライフタイムは次のとおりです:

• デフォルトでは365日。
• buffered_token_expiration_limit機能フラグを有効にした場合、400日。この拡張された制限は、GitLab Dedicatedでは利用できません。

アクセストークンは、GitLabにプログラムからアクセスする際に必要となる唯一のトークンです。ただし、セキュリティ要件のある組織では、これらのトークンを定期的にローテーションすることを必須とし、より強力な保護を適用したい場合があります。

ライフタイムを設定する

ライフタイムを設定できるのはGitLabの管理者のみです。空白のままにすると制限なしを意味します。

アクセストークンのライフタイムを設定するには、次の手順を実行します:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限セクションを展開します。
4. Maximum allowable lifetime for access tokens (days)（アクセストークンの最大許容ライフタイム(日数)）フィールドに入力します。
5. 変更を保存を選択します。

アクセストークンのライフタイムを設定すると、GitLabは次のように動作します:

• 新しいパーソナルアクセストークンに対してライフタイムを適用し、許可されたライフタイムを超えない範囲で有効期限を設定するようにユーザーに要求します。
• 3時間後に、有効期限が設定されていないか、許可されたライフタイムを超えている古いトークンを失効させます。失効する前に、管理者が許可されたライフタイムを変更または削除できるように、3時間の猶予が与えられます。

SSHキーのライフタイムを制限する

ユーザーは必要に応じて、SSHキーのライフタイムを指定できます。このライフタイムは必須ではなく、任意の日数に設定できます。

SSHキーは、GitLabにアクセスするためのユーザー認証情報です。ただし、セキュリティ要件のある組織では、これらのキーを定期的にローテーションすることを必須とし、より強力な保護を適用したい場合があります。

ライフタイムを設定する

ライフタイムを設定できるのはGitLabの管理者のみです。空白のままにすると制限なしを意味します。

SSHキーのライフタイムを設定するには、次の手順を実行します:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限セクションを展開します。
4. Maximum allowable lifetime for SSH keys (days)（SSHキーの最大許容ライフタイム(日数)）フィールドに入力します。
5. 変更を保存を選択します。

SSHキーのライフタイムを設定すると、GitLabは次のように動作します:

• 新しいSSHキーに対して、許可されたライフタイムを超えない範囲で有効期限を設定するようにユーザーに要求します。最大許容ライフタイムは次のとおりです:
  • デフォルトでは365日。
  • buffered_token_expiration_limit機能フラグを有効にした場合、400日。この拡張された制限は、GitLab Dedicatedでは利用できません。
• 既存のSSHキーにライフタイム制限を適用します。有効期限が設定されていないキーや最大許容ライフタイムを超えているキーは、ただちに無効になります。

ユーザーOAuthアプリケーション設定

前提要件:

• 管理者である必要があります。

ユーザーOAuthアプリケーション設定は、ユーザーがGitLabをOAuthプロバイダーとして使用するために、アプリケーションを登録できるかどうかを制御します。この設定は、ユーザーが所有するOAuthアプリケーションに影響しますが、グループが所有するOAuthアプリケーションには影響しません。

ユーザーOAuthアプリケーション設定をオンまたはオフにするには、次の手順を実行します:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限セクションを展開します。
4. ユーザーOAuthアプリケーションチェックボックスをオンまたはオフにします。
5. 変更を保存を選択します。

OAuth認証

前提要件:

• 管理者である必要があります。

OAuth認証設定は、ユーザーがクライアント認証情報を使わずに、自身を認可するためのOAuthリソースオーナーパスワード認証情報フローを使用できるかどうかを制御します。

この設定をオンまたはオフにするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. OAuthを選択します。
3. OAuth認証を選択します。
4. Allow user to use resource owner password credentials flow without OAuth client credentials（ユーザーにOAuthクライアント認証情報なしでリソースオーナーパスワード認証情報フローを使用することを許可する）チェックボックスをオンまたはオフにします。
5. 変更を保存を選択します。

ユーザープロファイル名の変更を無効にする

監査イベントでユーザーの詳細の整合性を維持するために、GitLab管理者はユーザーがプロファイル名を変更できないようにすることができます。

この設定を行うには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. ユーザーがプロファイル名を変更できないようにするを選択します。

この設定を行っても、GitLab管理者は引き続き管理者エリアまたはAPIでユーザー名を更新できます。

ユーザーが組織を作成できないようにする

デフォルトでは、ユーザーは組織を作成できます。GitLab管理者は、ユーザーが組織を作成できないようにすることができます。

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. ユーザーが組織を作成できるようにするチェックボックスをオフにします。

新しいユーザーがトップレベルグループを作成できないようにする

デフォルトでは、新しいユーザーはトップレベルグループを作成できます。GitLab管理者は、新しいユーザーがトップレベルグループを作成できないようにすることができます:

• GitLab UIで、このセクションに記載された手順を実行する。
• アプリケーション設定APIを使用する。

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. 新しいユーザーがトップレベルのグループを作成できるようにしますチェックボックスをオフにします。

メンバー以外のユーザーがプロジェクトとグループを作成できないようにする

デフォルトでは、ゲスト権限を持つユーザーはプロジェクトとグループを作成できます。GitLab管理者は、この動作を防ぐことができます:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. ゲスト権限以上を持つユーザーにグループと個人プロジェクトの作成を許可するチェックボックスをオフにします。
5. 変更を保存を選択します。

ユーザーが自分のプロファイルを非公開にできないようにする

デフォルトでは、ユーザーは自分のプロファイルを非公開にできます。GitLab管理者はこの設定を無効にすることで、すべてのユーザープロファイルを公開するように強制できます。この設定は、内部ユーザー（「ボット」と呼ばれることもあります）には影響しません。

ユーザーが自分のプロファイルを非公開にできないようにするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. ユーザーが自分のプロファイルを非公開にできるようにしますチェックボックスをオフにします。
5. 変更を保存を選択します。

この設定をオフにした場合:

• すべての非公開ユーザープロファイルが公開されます。
• 新しいユーザーのプロファイルをデフォルトで非公開にしますオプションもオフになります。

この設定を再度有効にすると、ユーザーが以前に設定していたプロファイルの表示レベルが選択されます。

新しいユーザーのプロファイルをデフォルトで非公開に設定する

デフォルトでは、新しく作成されたユーザーには公開プロファイルがあります。GitLab管理者は、新しいユーザーのプロファイルをデフォルトで非公開にするよう設定できます:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. 新しいユーザーのプロファイルをデフォルトで非公開にしますチェックボックスをオンにします。
5. 変更を保存を選択します。

ユーザーが自分のアカウントを削除できないようにする

デフォルトでは、ユーザーは自分のアカウントを削除できます。GitLab管理者は、ユーザーが自分のアカウントを削除できないようにすることができます:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. 設定 > 一般を選択します。
3. アカウントと制限を展開します。
4. ユーザーが自分のアカウントを削除することを許可するチェックボックスをオフにします。

トラブルシューティング

413 Request Entity Too Large（リクエストエンティティが大きすぎます）

GitLabでコメントや返信にファイルを添付する際、おそらく添付ファイルの最大サイズがWebサーバーで許可されている値よりも大きくなっています。

Linuxパッケージインストール環境で添付ファイルの最大サイズを200 MBに増やすには、次の手順を実行します:

1. /etc/gitlab/gitlab.rbに次の行を追加します:

   nginx['client_max_body_size'] = "200m"

2. 添付ファイルの最大サイズを増やします。

This repository has exceeded its size limit（このリポジトリはサイズ制限を超えています）

Railsの例外ログに次のような断続的なプッシュエラーが記録される場合があります:

Your push to this repository cannot be completed because this repository has exceeded the allocated storage for your project.

ハウスキーピングタスクが原因で、リポジトリサイズが増加している可能性があります。この問題を解決するには、次のいずれかの対処を行うことで、短期的または中期的な効果が期待できます:

• リポジトリサイズ制限を増やす
• リポジトリサイズを削減する