グループを管理する

グループを使用して、関連する1つ以上のプロジェクトを同時に管理します。

グループのREADMEを追加する

Readmeファイルを追加して、チームに関する情報を提供し、ユーザーにプロジェクトへのコントリビュートを促すことができます。Readmeはグループの概要ページに表示されます。すべてのグループメンバーがReadmeを表示および編集できます。

前提条件:

• グループ設定からReadmeを作成するには、グループのオーナーロールが必要です。

グループのReadmeを追加するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. グループのREADMEセクションで、Readmeを追加を選択します。この操作により、README.mdファイルを含む新しいプロジェクトgitlab-profileが作成されます。
4. README作成のプロンプトで、READMEを作成し追加を選択します。Web IDEにリダイレクトされ、Readmeファイルが作成されます。
5. Web IDEで、README.mdファイルを編集してコミットします。

グループのオーナーを変更する

グループのオーナーを変更できます。各グループには常に、オーナーロールを持つ人間のメンバーが少なくとも1人存在している必要があります。内部ユーザー（「ボット」）とサービスアカウントは、グループの唯一のオーナーになることはできません。

• 管理者として、次の手順を実行します:
  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
  2. 管理 > メンバーを選択します。
  3. 別のメンバーにオーナーロールを付与します。
  4. ページを更新します。これで、元のオーナーからオーナーロールを削除できるようになります。
• 現在のグループのオーナーとして、次を実行します:
  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
  2. 管理 > メンバーを選択します。
  3. 別のメンバーにオーナーロールを付与します。
  4. 新しいオーナーにサインインしてもらい、あなたのオーナーロールを削除してもらいます。

グループのパスを変更する

グループのパス（グループURL）を変更すると、意図しない副次効果が発生する可能性があります。続行する前に、プロジェクトとAPIのリダイレクトの動作を確認してください。

別のグループまたはユーザーが要求できるようにパスを変更する場合は、グループの名前も変更する必要があります。名前とパスは一意である必要があります。

元のネームスペースの所有権を保持し、URLリダイレクトを保護するには、代わりに新しいグループを作成し、プロジェクトをそのグループに転送します。

グループパス（グループURL）を変更するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 詳細設定セクションを展開します。
4. グループのURLの変更で、新しい名前を入力します。
5. グループのURLの変更を選択します。

グループのデフォルトブランチ保護を変更する

GitLabインスタンスの管理者は、インスタンス内のすべてのプロジェクトに対してデフォルトブランチ保護を設定できます。そのインスタンス内のグループは、グローバルレベルで設定されたブランチ保護を継承します。グループオーナーは、グループ内のプロジェクトに対してインスタンス設定をオーバーライドできます。GitLab PremiumまたはUltimateでは、インスタンスの管理者はこの権限を無効にできます。

最初のブランチにカスタム名を使用する

GitLabで新しいプロジェクトを作成すると、最初のプッシュでデフォルトブランチが作成されます。グループオーナーは、グループのニーズに合わせて、グループのプロジェクトの最初のブランチをカスタマイズできます。

グループをアーカイブする

グループとそのすべてのサブグループとプロジェクトをアーカイブします。アーカイブすると、グループとそのコンテンツは読み取り専用になり、グループデータは将来の参照用に保持されます。

さらに、アーカイブグループは次のようになります:

• グループページにArchivedバッジを表示します
• 無効タブがマイワークページと検索ページに表示されます
• 別のネームスペースに転送できません

既知の制限事項

アーカイブされたグループからのイシューは、イシュー585677が解決されるまで、イシューボードに表示され続けます。

前提条件:

• グループの管理者であるか、オーナーのロールを持っていること。

グループをアーカイブするには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 高度な設定を展開します。
4. グループのアーカイブセクションで、アーカイブを選択します。

マイワークリストビューから直接グループをアーカイブするには、次の手順を実行します:

1. 上部のバーで、検索または移動先を選択します。
2. すべてのグループを表示を選択します。
3. メンバータブで、アーカイブするグループを見つけて（ ）を選択します。
4. アーカイブを選択します。

この操作は、他のリストされたページでも使用できます。

グループのアーカイブを解除する

グループとそのすべてのサブグループとプロジェクトをアーカイブ解除します。グループをアーカイブ解除すると、次のようになります:

• 読み取り専用の制限がグループとそのコンテンツから削除されます。
• グループとそのサブグループおよびプロジェクトは、グループリストの有効またはメンバータブに戻ります。

前提条件:

• グループの管理者であるか、オーナーのロールを持っていること。

グループをアーカイブ解除するには、次の手順に従います:

1. アーカイブされたグループを見つけます。
   1. 上部のバーで、検索または移動先を選択します。
   2. すべてのグループを表示を選択します。
   3. 無効タブで、グループを選択します。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 高度な設定で、展開を選択します。
4. グループのアーカイブ解除セクションで、アーカイブ解除を選択します。

マイワークリストビューから直接グループをアーカイブ解除するには、次の手順を実行します:

1. 上部のバーで、検索または移動先を選択します。
2. すべてのグループを表示を選択します。
3. 無効タブで、アーカイブ解除するグループを見つけて（ ）を選択します。
4. アーカイブ解除を選択します。

この操作は、他のリストされたページでも使用できます。

グループを転送する

グループを転送して、同じGitLabインスタンス内の別の場所に移動します。次のことが可能です。

• サブグループを別の親グループに転送します。
• トップレベルグループをサブグループに変換します。
• サブグループをトップレベルグループに変換します。

前提条件:

• ソースグループおよび宛先グループのオーナーロール。
• 宛先グループでサブグループ作成を有効にする（該当する場合）。

グループを転送するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 詳細設定セクションを展開します。
4. グループを転送するを選択します。
5. ドロップダウンリストから、グループを選択します。
6. グループを転送するを選択します。

転送を確定した後:

• グループは非同期に転送されます。
• 転送が完了または失敗した後、確認メールが送信されます。
• 古いグループURLは新しいグループURLにリダイレクトされます。新しいグループURLを表示するには、ページを更新する。大規模なグループの場合は、転送が完了するまで待ってから、宛先ネームスペースでグループを表示できます。

グループを転送した後、以下を確認してください:

• ローカルリポジトリのリモートを新しいURLに更新していること。
• グループメンバーのアクセスと権限を確認していること。
• 必要に応じて、パッケージの設定を更新していること。
• CI/CDパイプラインとインテグレーションをテストしていること。

グループを別のGitLabインスタンスにコピーする必要がある場合は、直接転送でグループを移行します。

転送されるデータ

グループの転送には以下が含まれます:

• グループ内のすべてのサブグループとプロジェクト
• 明示的なグループメンバーシップとロール
• グループの設定と設定

既知の問題

グループを転送する際は、以下の制限事項に注意してください。

メンバーシップの制限は、次のとおりです:

• 継承されたメンバーシップは失われます。直接のグループメンバーのみが転送されます。
• グループのオーナーが継承されたメンバーシップを持っている場合、グループを転送するユーザーが新しいオーナーになります。

表示レベルとアクセス制限は、次のとおりです:

• 宛先の親グループの表示レベルが低い場合、すべてのサブグループおよびプロジェクトの表示レベル設定は、宛先の親グループの表示レベルに一致するように調整されます。
• リポジトリのURLが変更されます。ローカルリポジトリを更新して、新しい場所を指定する必要があります。詳細については、リポジトリページの変更を参照してください。

パッケージとコンテナレジストリの制限は、次のとおりです:

• 宛先グループがトップレベルグループであり、NPMパッケージがNPM命名規則に従って、グループ内のいずれかのプロジェクトまたはそのサブグループ内に存在する場合、転送は失敗します。
• グループエンドポイントを使用する既存のパッケージは、グループレベルのエンドポイントを設定するためのパッケージの手順に従って更新する必要があります。
• パッケージがインスタンスレベルのエンドポイントを使用し、グループが別のトップレベルグループに移動された場合、既存のパッケージ名を更新する必要があります。

サブスクリプションの制限は、次のとおりです:

• GitLab.comでサブスクリプションを使用しているトップレベルグループは転送できません。転送を可能にするには、最初にトップレベルグループのサブスクリプションを削除する必要があります。次に、トップレベルグループをサブグループとして別のトップレベルグループに転送できます。

メール通知を無効にする

グループに関連するすべてのメール通知を無効にすることができます。これには、サブグループとプロジェクトが含まれます。

メール通知を無効にするには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. メール通知を有効にするチェックボックスをオフにします。

メール通知で差分プレビューを無効にする

マージリクエストでコードにコメントすると、GitLabは参加者へのメール通知に差分の数行を含めます。一部の組織ポリシーでは、メールを安全性の低いシステムとして扱うか、メールのインフラストラクチャを自身で管理していない場合があります。このため、IPまたはソースコードのアクセス制御にリスクが生じる可能性があります。

前提条件:

• グループのオーナーのロールを持っている必要があります。

グループ内のすべてのプロジェクトの差分プレビューを無効にするには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能を展開します。
4. 差分プレビューを含めるをオフにします。
5. 変更を保存を選択します。

グループおよびプロジェクトアクセストークンの有効期限メール

次のグループおよびプロジェクトメンバーは、まもなく期限切れになるアクセストークンに関する通知メールを受信します:

• グループアクセストークンの通知メールを受信するメンバー:
  • オーナーロールを持つメンバー。
  • GitLab 17.7以降で、グループまたはその親グループに適切な設定が構成されている場合は、グループのオーナーロールを継承するメンバー。
• プロジェクトアクセストークンの通知メールを受信するメンバー:
  • メンテナーまたはオーナーロールを持つプロジェクトのメンバー。
  • GitLab 17.7以降では、プロジェクトがグループに属しているためにメンテナーまたはオーナーロールを継承したプロジェクトメンバー（そのグループまたは親グループに適切な設定が構成されている場合）

次の手順に従うと、グループの継承されたメンバーへの通知を有効にできます:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能を展開します。
4. **当グループ内のグループとプロジェクトアクセストークンに関する有効期限通知メールは以下の対象に発送すべきです:**で、グループまたはプロジェクトのすべての直接メンバーと継承メンバーを選択します。
5. オプション。すべてのサブグループに実施するチェックボックスをオンにします。
6. 変更を保存を選択します。

詳細については、以下を参照してください:

• グループについては、グループアクセストークンのドキュメントを参照してください。
• プロジェクトについては、プロジェクトアクセストークンのドキュメントを参照してください。

グループアクセストークンの有効期限に関する追加のWebhookトリガーを追加する

GitLabは、グループトークンの有効期限が切れる前に、複数の有効期限メールを送信し、関連するWebhookをトリガーします。デフォルトでは、これらのWebhookはトークンの有効期限が切れる7日前にトリガーされます。

これらのWebhookがトークンの有効期限が切れる60日前と30日前にもトリガーされるよう設定するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. グループアクセストークン有効期限に対する追加のWebhookトリガーを追加するチェックボックスを選択します。
5. 変更を保存を選択します。

グループメンションを無効にする

ユーザーが会話に追加されたり、ユーザーがメンバーになっているグループに誰かがメンションすると通知されたりするのを防ぐことができます。

メンションが無効になっているグループは、オートコンプリートドロップダウンリストでそれに応じて視覚化されます。

これらの視覚的な合図は、多数のユーザーがいるグループに特に役立ちます。

グループメンションを無効にするには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. グループメンションは無効ですを選択します。
5. 変更を保存を選択します。

エンタープライズユーザーの個人のスニペットを制限する

グループ内のエンタープライズユーザーが個人のネームスペースにスニペットを作成できないようにすることができます。無効になっている場合でも、エンタープライズユーザーはプロジェクトスニペットを作成し、既存の個人スニペットを表示および編集できます。

前提条件:

• グループのオーナーのロールを持っている必要があります。

エンタープライズユーザーの個人のスニペットを制限するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. 個人のスニペットを許可するチェックボックスをオフにします。
5. 変更を保存を選択します。

グループへの招待を禁止する

GitLab.comでは、ユーザーがトップレベルグループのサブグループまたはプロジェクトに新しいメンバーを招待する機能を削除できます。これにより、グループのオーナーも招待を送信できなくなります。ユーザーを再度招待するには、この設定を無効にする必要があります。

GitLab Self-ManagedおよびGitLab Dedicatedのインスタンスでは、インスタンス全体のユーザー招待を禁止できます。詳細については、グループとプロジェクトへの招待の禁止を参照してください。

前提条件:

• グループのオーナーのロールを持っている必要があります。

グループへの招待を禁止するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. グループ/プロジェクトメンバーの招待を無効にするを選択します。
5. 変更を保存を選択します。

メンバーをCSVとしてエクスポートする

グループまたはサブグループのメンバーリストをCSVとしてエクスポートできます。

1. 上部のバーで、検索または移動先を選択して、グループまたはサブグループを見つけます。
2. 管理 > メンバーを選択します。
3. CSVとしてエクスポートを選択します。
4. CSVファイルが生成されると、リクエストしたユーザーに添付ファイルとしてメールで送信されます。

出力には、直接メンバーと祖先グループから継承されたメンバーがリストされます。選択したグループにMinimal Accessを持つメンバーの場合、Max RoleとSourceはサブグループのメンバーシップから派生します。イシュー390358は、グループメンバーCSVエクスポートリストがUIメンバーリストと一致しないことに関するディスカッションを追跡します。

制限付きアクセスをオンにする

前提条件:

• グループのオーナーのロールを持っている必要があります。
• グループまたはそのサブグループまたはプロジェクトの1つが外部で共有されていない状態であること。

制限付きアクセスをオンにするには、次の手順に従います:

1. 左側のサイドバーで、設定 > 一般を選択します。
2. 権限とグループ機能を展開します。
3. シートコントロールで、制限されたアクセスを選択します。

制限付きアクセスをオンにすると、グループ階層外のグループを招待できないようにする設定が自動的にオンになります。

必要に応じて、グループとそのサブグループのプロジェクト共有を個別に構成できます。

グループのユーザーキャパシティを設定する

前提条件:

• グループのオーナーの役割を割り当てられていること。

ユーザーキャパシティを設定するには、次手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。トップレベルグループでのみキャパシティを設定できます。
2. 設定 > 一般を選択します。
3. 権限とグループ機能を展開します。
4. シートの管理から、ユーザーキャパシティを設定するチェックボックスを選択し、フィールドにユーザー数を入力します。
5. 変更を保存を選択します。

グループ内のユーザー数がユーザーキャパシティ値よりも既に多い場合でも、ユーザーは削除されません。ただし、承認なしに追加することはできません。

ユーザーキャパシティを増やしても、保留中のメンバーは承認されません。

ユーザー上限を設定すると、グループ階層外のグループを招待できないようにする設定が自動的にオンになります。

グループのユーザーキャパシティを削除する

ユーザーキャパシティを削除して、グループに追加できるメンバーの数を無制限にすることができます。

前提条件:

• グループのオーナーの役割を割り当てられていること。

ユーザーキャパシティを削除するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能を展開します。
4. シートの管理からオープンアクセスを選択します。
5. 変更を保存を選択します。

グループの保留中のメンバーを承認する

請求対象ユーザーの数がユーザーキャパシティに達すると、新しいメンバーは保留状態になります。追加するには、彼らを承認する必要があります。

保留中のメンバーは請求対象としてカウントされません。承認されて保留状態でなくなった後にのみ、そのメンバーが請求対象としてカウントされます。

前提条件:

• グループのオーナーの役割を割り当てられていること。

ユーザーキャパシティを超過したために保留になっているメンバーを承認するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 使用量クォータを選択します。
3. シートタブのアラートの下にある保留中のユーザー承認を表示を選択します。
4. 承認するメンバーごとに、承認を選択します。

組み込みプロジェクトテンプレートを制御する

組み込みのプロジェクトテンプレートを使用すると、スターターファイルがあらかじめ用意された新しいプロジェクトを作成できます。ユーザーがグループ内でプロジェクトを作成する際に、これらのテンプレートを利用できるかどうかを制御できます。また、すべてのサブグループに選択を適用することもできます。

この設定では、カスケード継承が使用されます:

• グループは、最も近い祖先グループまたはインスタンスから設定を継承します。
• グループに設定された値は、継承された値を上書きします。
• グループに設定を適用すると、すべてのサブグループがそれを継承し、変更できなくなります。
• グループの設定を変更すると、新しい値がすべてのサブグループにカスケードされます。

前提条件:

• グループのオーナーのロールを持っている必要があります。

グループの組み込みプロジェクトテンプレートを制御するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 組み込みのプロジェクトテンプレートを展開します。
4. 組み込みのプロジェクトテンプレートを有効にするチェックボックスをオンまたはオフにします。
5. オプション。サブグループがこの設定を変更できないようにするには、すべてのサブグループに実施するチェックボックスを選択します。
6. 変更を保存を選択します。

管理者がインスタンスにこの設定を適用している場合、または親グループがサブグループに適用している場合、その設定はロックされており、変更することはできません。

グループファイルテンプレート

グループファイルテンプレートを使用すると、グループ内のすべてのプロジェクトで、一般的なファイルタイプの一連のテンプレートを共有できます。これは、インスタンステンプレートリポジトリに似ています。選択したプロジェクトは、そのページに記載されているのと同じ命名規則に従う必要があります。

テンプレートソースとしてグループ内のプロジェクトのみを選択できます。これにはグループと共有されているプロジェクトが含まれますが、構成されているグループのサブグループまたは親グループ内のプロジェクトは除外されます。

サブグループと直属の親グループの両方に対して、この機能を設定できます。サブグループ内のプロジェクトは、そのサブグループと直属の親グループのテンプレートにアクセスできます。

イシューとマージリクエストのテンプレートを作成する方法については、説明テンプレートを参照してください。

グループをテンプレートソースとして設定して、グループレベルでプロジェクトテンプレートを定義します。詳細については、グループレベルのプロジェクトテンプレートを参照してください。

グループファイルテンプレートを有効にする

グループファイルテンプレートを有効にするには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. テンプレートセクションを展開します。
4. テンプレートリポジトリとして機能するプロジェクトを選択します。
5. 変更を保存を選択します。

グループマージチェック設定

グループオーナーは、トップレベルグループでマージリクエストチェックを設定できます。これは、すべてのサブグループとプロジェクトに適用されます。

設定がサブグループまたはプロジェクトによって継承されている場合、継承元のサブグループまたはプロジェクトで変更することはできません。

マージに成功したパイプラインを必須にする

グループ内のすべての子プロジェクトで、マージ前に完全かつ成功したパイプラインを必須にするように設定できます。

プロジェクトレベルの設定も参照してください。

前提条件:

• グループのオーナーであること。

この設定を有効にするには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. マージリクエストを展開します。
4. マージチェックで、パイプラインが完了しているを選択します。これを設定すると、パイプラインがない場合はマージリクエストのマージも防止されます。
5. 変更を保存を選択します。

スキップされたパイプラインの後にマージを許可する

スキップされたパイプラインを設定して、マージリクエストがマージされないようにすることができます。

プロジェクトレベルの設定も参照してください。

前提条件:

• グループのオーナーであること。

この動作を変更するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. マージリクエストを展開します。
4. マージチェックの下で次を行います:
   • パイプラインが完了しているを選択します。
   • スキップされたパイプラインは成功したと見なされますを選択します。
5. 変更を保存を選択します。

すべてのスレッドが解決されるまでマージを禁止する

すべてのスレッドが解決されるまで、マージリクエストがマージされないようにすることができます。この設定を有効にすると、グループ内の子プロジェクトでは、少なくとも1つの未解決スレッドがあるマージリクエストの未解決スレッド数がオレンジ色で表示されます。

前提条件:

• グループのオーナーであること。

この設定を有効にするには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. マージリクエストを展開します。
4. マージチェックで、すべてのスレッドが解決しているを選択します。
5. 変更を保存を選択します。

マージリクエストAPIでコミットSHAを要求する

マージリクエストAPIでコミットSHAを要求し、レビューされたコミットのみがマージされるようにします。この設定が有効になっている場合、GitLabはshaパラメータを省略したマージリクエストをマージするエンドポイントへの呼び出しを拒否し、400エラーを返します。shaパラメータがソースブランチの現在のHEADと一致しない場合、マージは失敗します。

この設定は、GitLab 19.2以降で作成されたグループではデフォルトで有効になっています。

前提条件:

• グループのオーナーロール。

マージリクエストAPIでコミットSHAを要求するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. マージリクエストを展開します。
4. Require commit SHA on merge requests APIチェックボックスを選択します。
5. オプション。この設定をすべてのサブグループに適用し、サブグループが変更できないようにするには、すべてのサブグループに実施するチェックボックスを選択します。
6. 変更を保存を選択します。

管理者は、すべてのグループに対してインスタンス全体のデフォルトを設定できます。親グループが上書きしない限り、新しいグループはこの値を継承します。

前提条件:

• インスタンスへの管理者アクセス権。

すべてのグループのデフォルトを設定するには:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > 一般を選択します。
3. マージリクエストを展開します。
4. Require commit SHA on merge requests APIチェックボックスを選択します。
5. オプション。インスタンス上のすべてのグループにこの設定を適用し、グループが変更できないようにするには、Enforce this setting for all groups on this instanceチェックボックスを選択します。
6. 変更を保存を選択します。

グループのマージリクエスト承認設定

グループ承認設定は、トップレベルグループのサブグループおよびプロジェクトにおけるプロジェクトマージリクエスト承認設定のデフォルトを定義します。グループの防止設定を有効にすると、同等のプロジェクト設定がロックされ、プロジェクトメンテナーは変更できなくなります。防止設定が無効のままの場合、プロジェクトメンテナーは個々のプロジェクトに対してそれを構成できます。詳細については、インスタンスまたはトップレベルグループから設定をカスケードするを参照してください。

グループのマージリクエスト承認設定を表示するには、次の手順に従います:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. マージリクエストの承認セクションを展開します。
4. 必要な設定を選択します。
5. 変更を保存を選択します。

承認設定を承認ルールと混同しないようにしてください。グループのマージリクエスト承認ルールを設定する機能のサポートは、エピック4367で追跡されます。

グループアクティビティ分析

グループの場合、過去90日間に作成されたマージリクエスト、イシュー、およびメンバーの数を確認できます。

グループウィキへの変更は、グループアクティビティ分析には表示されません。

グループのアクティビティを表示する

次の手順に従うと、グループで実行された最新のアクションをブラウザまたはRSSフィードで表示できます:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、管理 > アクティビティを選択します。

Atom形式でアクティビティフィードを表示するには、RSS（ ）アイコンを選択します。

GitLabクレジットのユーザーデータを表示する

前提条件:

• グループのオーナーであること。
• データを表示するグループが、トップレベルグループであること。

GitLabクレジットダッシュボードにユーザーデータを表示するには、次の手順を実行します:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. GitLabクレジットダッシュボードで、ユーザーデータを表示チェックボックスをオンにします。
5. 変更を保存を選択します。