グループを管理する

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

前提要件:

• グループの管理者であるか、オーナーのロールを持っている必要があります。

グループをアーカイブするには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > 一般を選択します。
3. 高度な設定を展開します。
4. グループのアーカイブセクションで、アーカイブを選択します。

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

1. 左側のサイドバーで、検索または移動先を選択します。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. すべてのグループを表示を選択します。
3. メンバータブで、アーカイブするグループを見つけて( )を選択します。
4. アーカイブを選択します。

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

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

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

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

前提要件:

• グループの管理者であるか、オーナーのロールを持っている必要があります。

グループをアーカイブ解除するには:

1. アーカイブされたグループを見つけます。
   1. 左側のサイドバーで、検索または移動先を選択します。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
   2. すべてのグループを表示を選択します。
   3. 非アクティブタブで、グループを選択します。
2. 左側のサイドバーで、設定 > 一般を選択します。
3. 高度な設定で、全て展開を選択します。
4. グループのアーカイブ解除セクションで、アーカイブ解除を選択します。

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

1. 左側のサイドバーで、検索または移動先を選択します。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. すべてのグループを表示を選択します。
3. 非アクティブタブで、アーカイブ解除するグループを見つけて( )を選択します。
4. アーカイブ解除を選択します。

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

グループを転送する

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

• サブグループを新しい親グループに転送します。
• トップレベルグループを目的のグループに転送して、サブグループに変換します。
• サブグループを現在のグループから転送して、トップレベルグループに変換します。

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

グループを転送する際は、次の点に注意してください:

• グループの親を変更すると、意図しない副次効果が発生する可能性があります。リポジトリパスの変更時に何が起こるかをご覧ください。
• ローカルリポジトリを更新して、新しい場所を指定する必要があります。
• 直属の親グループの表示レベルがグループの現在の表示レベルよりも低い場合、サブグループとプロジェクトの表示レベルは、新しい親グループの表示レベルに合わせて変更されます。
• 明示的なグループメンバーシップのみが転送され、継承されたメンバーシップは転送されません。グループのオーナーが継承されたメンバーシップのみを持っている場合、グループにオーナーがいなくなります。この場合、グループを転送するユーザーがグループのオーナーになります。
• グループがトップレベルグループであり、グループ内のいずれかのプロジェクト、またはそのサブグループのいずれかに命名規則に従うNPMパッケージが存在する場合、転送は失敗します。
• アーカイブされたプロジェクトのcontainer_registryイメージは、転送前に削除する必要があります。詳細については、トラブルシューティングセクションを参照してください。
• グループレベルのエンドポイント（Maven、NuGet、PyPI、Composer、Debian）を使用する既存のパッケージは、グループレベルのエンドポイントを設定するためのパッケージの手順に従って更新する必要があります。
• パッケージがインスタンスレベルのエンドポイント（Maven 、npm 、Conan 1を使用し、グループが別のトップレベルグループに移動された場合、既存のパッケージ名を更新する必要があります。
• GitLab.comでサブスクリプションを使用しているトップレベルグループは転送できません。転送を可能にするには、最初にトップレベルグループのサブスクリプションを削除する必要があります。次に、トップレベルグループをサブグループとして別のトップレベルグループに転送できます。

前提要件:

• ソースグループとターゲットグループのオーナーロールが必要です。

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

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > 一般を選択します。
3. 高度な設定セクションを展開します。
4. グループの転送を選択します。
5. ドロップダウンメニューでグループ名を選択します。
6. グループの転送を選択します。

メール通知を無効にする

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

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

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. 変更を保存を選択します。

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

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

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

前提要件:

• グループのオーナーロールが必要です。

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

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. Disable Group/Project members invitation（グループ/プロジェクトメンバーの招待を無効にする）を選択します。
5. 変更を保存を選択します。

メンバーをCSV形式でエクスポートする

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

1. 左側のサイドバーで、検索または移動先を選択して、グループまたはサブグループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 管理 > メンバーを選択します。
3. CSV形式でエクスポートを選択します。
4. CSVファイルが生成されると、リクエストしたユーザーに添付ファイルとしてメールで送信されます。

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

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

制限付きアクセスを使用すると、超過料金を防げます。超過料金は、サブスクリプションのシート数を超えた場合に発生し、次回の四半期ごとの調整で支払う必要があります。

制限付きアクセスをオンにすると、サブスクリプションに残りのシートがない場合、グループは新しい請求対象ユーザーを追加できません。

前提要件:

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

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

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

既知のイシュー

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

• シート数は、次の場合はまだ超過する可能性があります:
  • 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人のデベロッパーを追加すると、請求対象のシートを消費しないゲストユーザーであっても、ユーザーを追加できなくなります。

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

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

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

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

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

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

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

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

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（ ）アイコンを選択します。