グループを管理する

グループを使用して、関連する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バッジを表示します
• 無効タブがあなたの作業ページと検索ページに表示されます
• 別のネームスペースに転送できません

既知の制限事項

アーカイブされたグループからのイシューは、issue 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に更新します。
• グループメンバーのアクセスと権限を確認します。
• 必要に応じて、パッケージの設定を更新します。
• 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. シートコントロールで、制限されたアクセスを選択します。

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

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

SAML、SCIM、およびLDAPによるプロビジョニングの動作

制限付きアクセスが有効になっていて、サブスクリプションのコード行が利用できない場合、SAML、SCIM、またはLDAPを介してプロビジョンされたユーザーには、設定されたアクセスレベルの代わりに最小アクセスロールが割り当てられます。この動作により、GitLab.comおよびSelf-Managed Ultimateで、請求対象のコード行を消費せずに、同期を続行できます。

最小アクセスロールを持つユーザーは、認証してグループにアクセスできますが、制限された権限があります。コード行が利用可能になると、意図したアクセスレベルにプロモートできます。請求対象ロールを持つ既存のユーザーは、この動作の影響を受けません。

コード行の使用状況を表示し、最小アクセスを持つユーザーを管理できます。

既知の問題

制限付きアクセスをオンにすると、次の既知の問題が発生し、超過が発生する可能性があります:

• シート数は、次の場合はまだ超過する可能性があります:
  • SAML、SCIM、またはLDAPを使用して新しいメンバーを追加し、サブスクリプションのシート数を超えた場合。最小アクセスのフォールバック機能が有効になっている場合、ユーザーはブロックされる代わりに最小アクセスを割り当てられます。
  • オーナーロールを持つ複数のユーザーが同時にメンバーを追加している場合。
  • 新しい請求対象メンバーが招待の承認を遅らせている場合。ユーザーを招待した場合、招待されたユーザーが承認するまでは請求対象シートを消費しません。承認が遅れている間に、他のユーザーを招待して追加することができます。ただし、承認を遅らせていたユーザーが最終的に承認した時点で請求対象シートが消費されるため、すでにシートの上限に達している場合は超過が発生する可能性があります。
• 現在のサブスクリプションよりも少ないユーザー数でGitLabセールスチームを通じてサブスクリプションを更新すると、超過料金が発生します。この料金を回避するには、更新が開始される前に追加のユーザーを削除してください。たとえば、20人のユーザーがいて、15人のユーザーに対してサブスクリプションを更新する場合、5人の追加ユーザーに対して超過料金が請求されます。

さらに、制限付きアクセスによって、標準の超過料金が発生しないフローがブロックされる場合があります:

• 請求対象ロールに更新または追加されたサービスボットが誤ってブロックされる。
• メールを介して既存の請求対象ユーザーを招待または更新すると、予期せずにブロックされる。

グループのユーザーキャパシティ

GitLab Self-Managedのユーザーキャパシティについては、こちらをご覧ください。

請求対象メンバーの数がユーザーキャパシティに達すると、グループオーナーは新規メンバーを承認する必要があります。

ユーザーキャパシティ機能を有効にしたグループは、グループとそのサブグループに対してグループ共有が無効になります。

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

前提条件:

• グループのオーナーの役割を割り当てられている必要があります。

ユーザーキャパシティを設定するには:

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

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

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

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

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

前提条件:

• グループのオーナーの役割を割り当てられている必要があります。

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

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

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

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

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

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

前提条件:

• グループのオーナーの役割を割り当てられている必要があります。

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

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

既知の問題

グループ、サブグループ、またはプロジェクトが外部で共有されている場合、ユーザーキャパシティを有効にすることはできません。グループ、サブグループ、またはプロジェクトが外部で共有されている場合、階層内のレベルに関係なく、ネームスペース階層の外部で共有されます。

グループ、サブグループ、またはプロジェクトが外部で共有されている場合にユーザーキャパシティが適用されるようにするには、トップレベルネームスペースでのみグループ共有を制限します。トップレベルでネームスペースを制限することで、同じネームスペースでの招待の許可、外部共有からの新しいユーザー（シート）の追加の防止が可能となります。

GitLab.com Ultimateには、請求対象ユーザーがユーザーキャパシティを超えている場合、ゲストユーザーをグループに追加できないという既知のイシューがあります。たとえば、ユーザーキャパシティが5人で、3人のデベロッパーと2人のゲストがいるとします。さらに2人のデベロッパーを追加すると、請求対象のシートを消費しないゲストユーザーであっても、ユーザーを追加できなくなります。

ユーザー上限から制限付きアクセスへの変更

ユーザー上限から制限付きアクセスに変更すると、保留中のすべてのメンバー（承認待ちのメンバーと招待されたメンバーの両方）が自動的に削除されます。ユーザーがメンバーとして承認されるようにするには、制限付きアクセスを有効にする前に、保留中のメンバーを承認または削除する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前提条件:

• グループのオーナーである必要があります。

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

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

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

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

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

前提条件:

• グループのオーナーである必要があります。

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

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

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

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

前提条件:

• グループのオーナーである必要があります。

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

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

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

グループの承認設定では、トップレベルグループ内のすべてのプロジェクトに対してプロジェクトのマージリクエスト承認設定を管理します。これらの設定は、グループに属するすべてのプロジェクトに反映されます。

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

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

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

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

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

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

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

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

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

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

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

前提条件:

• グループのオーナーである必要があります。
• データを表示するグループは、トップレベルグループである必要があります。

GitLabクレジットダッシュボードにユーザーデータを表示するには:

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