グループの管理

グループを使用して、1つまたは複数の関連プロジェクトを同時に管理できます。

note
自己管理されているお客様には、トップレベルのグループを1つ作成し、組織全体の概要を確認できるようにすることが有益な場合があります。すべてのグループの組織ビューを作成する取り組みの詳細については、エピック9266を参照してください。単一のトップレベルグループは、完全なセキュリティダッシュボードとセンター、脆弱性とコンプライアンスセンター、およびバリューストリーム分析を通じて、組織全体のインサイトを提供します。

グループの追加 README

グループのオーナーまたはメンバーとして、READMEを使用してチームに関する詳細情報を提供し、プロジェクトに貢献するユーザーを招待することができます。READMEはグループの概要ページに表示され、グループ設定で変更できます。グループのメンバー全員がREADMEを編集できます。

前提条件

  • グループ設定からREADMEを作成するには、グループのオーナーロールを持っている必要があります。

グループのREADMEを追加するには、以下の手順に従います：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. Group READMEセクションで、Add READMEを選択します。このアクションにより、README.md ファイルを含む新しいプロジェクトgitlab-profile が作成されます。
  4. README を作成するプロンプトが表示されたら、[Create and add README] を選択します。Web IDE にリダイレクトされ、README ファイルが作成されます。
  5. Web IDEで、README.md ファイルを編集してコミットします。

グループのオーナーの変更

グループのオーナーは変更できます。各グループには必ずオーナーロールを持つメンバーが1人以上いなければなりません。

  • 管理者として。
    1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
    2. 管理 > メンバーを選択します。
    3. 別のメンバーにオーナーロールを与えます。
    4. ページを更新します。これで元のオーナーからオーナーロールを削除できます。
  • 現在のグループのオーナーとして。
    1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
    2. 管理 > メンバーを選択します。
    3. 別のメンバーにオーナーロールを与えます。
    4. 新しいオーナーにサインインしてもらい、オーナーロールを削除してもらいます。

グループのパスの変更

グループのパス (グループのURL) を変更すると、意図しない副作用が生じることがあります。先に進む前に、リダイレクトの動作を読んでください。

他のグループやユーザーが使用できるようにパスを変更する場合は、グループの名前も変更する必要があります。名前もパスも一意でなければなりません。

グループ・パスを変更すると、新しいグループ・パスは新しいネームスペースになり、以下のリソースで既存のプロジェクト URL を更新する必要があります：

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

グループパス（グループURL）を変更するには：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 詳細」セクションを展開します。
  4. グループURLの変更」で、新しい名前を入力します。
  5. グループURLの変更」を選択します。
caution
ネームスペースにコンテナ・レジストリ・タグを持つプロジェクトが含まれている場合は、プロジェクトを移動できないため、ネームスペースの名前を変更することはできません。

グループのデフォルトブランチプロテクションの変更

デフォルトでは、すべてのグループは、グローバルレベルで設定されたブランチプロテクションを継承します。

特定のグループに対してこの設定を変更するには、グループレベルのデフォルトブランチプロテクションを参照してください。

この設定をグローバルに変更するには、初期デフォルトブランチプロテクションを参照してください。

初期ブランチにカスタム名を使う

GitLab 13.6で導入されました。

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

グループを別のグループと共有

プロジェクトをグループで共有するのと同様に、グループを別のグループで共有することができます。グループを招待するには、そのグループのメンバーである必要があります。あるグループ、例えばFrontend を、別のグループ、例えばEngineering と共有するには：

  1. Frontend グループに移動します。
  2. 管理 > メンバーを選択します。
  3. グループを招待] を選択します。
  4. 招待するグループの選択リストで、Engineering を選択します。
  5. 最大アクセスレベルとしてロールを選択します。
  6. 招待］を選択します。

Frontend グループをEngineering グループと共有します：

  • グループ] タブにEngineering グループが表示されます。
  • グループ]タブには、公開グループか非公開グループかに関係なく、グループが一覧表示されます。
  • Engineering グループのすべての直接メンバは、Frontend グループにアクセスできます。Frontend グループにアクセスできるEngineering の直接メンバは、Engineeringと同じアクセス レベルを保持しますが、グループの共有時に選択した最大アクセス レベルまでとなります。
  • Engineering グループの継承メンバは、Frontend グループにアクセスすることはできません。
  • Engineering グループの直接メンバーで、グループの利用クォータ ページでプロフィールの横にグループ招待バッジが表示されている場合は、Frontend グループの請求可能メンバーにカウントされます。

共有グループの削除

グループの共有を解除します：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 管理 > メンバーを選択します。
  3. グループ」タブを選択します。
  4. 削除するアカウントの右側で、グループの削除（{remove}）を選択します。

例えば、Engineering グループがFrontend グループと共有されている場合、Engineering グループの共有を解除します：

  • Engineering グループのすべての直接メンバーは、Frontend グループにアクセスできなくなります。
  • Engineering グループのメンバーは、Frontend グループの請求可能メンバーにカウントされなくなります。

グループの譲渡

グループを転送すると、同じGitLabインスタンス内のある場所から別の場所に移動させることができます。できます：

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

グループを別のGitLabインスタンスにコピーする必要がある場合は、直接転送によってグループをマイグレーションしてください。

グループ転送を行う場合は、ご注意ください。

  • グループの親を変更すると、意図しない副作用が発生する可能性があります。リポジトリパスが変更されたときに何が起こるかをご覧ください。
  • ソースグループとターゲットグループのオーナーロールを持っている必要があります。
  • 新しい場所を指すように、ローカルリポジトリを更新する必要があります。
  • 直接の親グループの可視性がグループの現在の可視性よりも低い場合、サブグループとプロジェクトの可視レベルは新しい親グループの可視性に合わせて変更されます。
  • グループのオーナーが継承されたメンバーシップのみを持つ場合、グループにはオーナーがいません。 この場合、グループを譲渡したユーザーがグループのオーナーとなります。
  • グループ内のプロジェクトやサブグループにnpm パッケージが存在する場合、転送は失敗します。
  • グループレベルのエンドポイントを使用する既存のパッケージ (Maven、NuGet、PyPI、Composer、Debian) は、パッケージのグループレベルのエンドポイントの設定手順に従って更新する必要があります。
  • パッケージがインスタンスレベルのエンドポイント(Maven、npm、Conan) を使用し、グループが別のルートレベルの名前空間に移動された場合、既存のパッケージ名を更新する必要があります。
  • Maven パッケージは、グループ転送後にグループレベルのエンドポイントからそれぞれのパッケージをインストールまたは公開できない命名規則に従っています。
  • GitLab.comにサブスクリプションがあるトップレベルグループは転送できません。転送を可能にするには、まずトップレベルグループのサブスクリプションを削除する必要があります。その後、トップレベルグループを別のトップレベルグループのサブグループとして転送することができます。

グループを転送するには

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 詳細」セクションを展開します。
  4. グループの削除セクションで、転送グループを選択します。
  5. ドロップダウンメニューでグループ名を選択します。
  6. 転送グループを選択します。

メール通知の無効化

GitLab 12.2で導入されました。

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

メール通知を無効にするには

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 権限とグループの機能」セクションを展開します。
  4. 電子メール通知を無効にする] を選択します。
  5. 変更を保存を選択します。

グループのメンションを無効にします。

GitLab 12.6 で導入されました。

会話にユーザが追加されたり、そのユーザがメンバーであるグループに誰かが言及した時に通知を受け取らないようにすることができます。

メンションが無効化されたグループは、オートコンプリートドロップダウンリストに表示されます。

特にユーザー数の多いグループには有効です。

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

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 権限とグループの機能」セクションを展開します。
  4. グループのメンションは無効です] を選択します。
  5. 変更を保存を選択します。

メンバーをCSVでエクスポート

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

  1. 左側のサイドバーで、「検索」を選択するか、「グループまたはサブグループ」を検索します。
  2. 左側のサイドバーで、[管理] > [メンバー]を選択します。
  3. CSVエクスポートを選択します。
  4. CSVファイルが生成されると、リクエストしたユーザーに添付ファイルとして電子メールで送信されます。

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

グループのユーザーキャップ

GitLabセルフマネージドのユーザーキャップの詳細については、ユーザーキャップをご覧ください。

請求可能なメンバー数がユーザーキャップに達すると、グループオーナーの承認者なしに新しいユーザーをグループに追加できなくなります。

ユーザーキャップ機能が有効なグループは、グループとそのサブグループのグループ共有が無効になります。

グループのユーザーキャップの指定

前提条件

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

ユーザーキャップを指定するには

  1. 左側のサイドバーで「検索」を選択するか、「検索」からグループを探します。トップレベルのグループにのみ上限を設定できます。
  2. 設定] > [全般]を選択します。
  3. 権限とグループ機能] を展開します。
  4. ユーザーの上限] ボックスに、希望するユーザー数を入力します。
  5. 変更を保存を選択します。

グループ内にユーザー上限値以上のユーザーがすでにいる場合、ユーザーは削除されません。ただし、承認者なしで追加することはできません。

ユーザー上限を増やしても、保留中のメンバーは承認されません。

グループのユーザーキャップの削除

ユーザー上限を削除することで、グループに追加できるメンバー数に制限がなくなります。

前提条件

  • グループのオーナー（Owner）ロールが割り当てられている必要があります。

ユーザーキャップを外すには

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 権限とグループ機能] を展開します。
  4. ユーザー キャップボックスで、値を削除します。
  5. 変更を保存を選択します。

ユーザー上限を引き下げても、保留中のメンバーは承認されません。

グループの保留メンバーを承認者

請求可能なユーザー数がユーザーキャップに達すると、新しいメンバーは保留状態になり、承認者が必要になります。

保留中のメンバーは課金対象としてカウントされません。承認され、保留状態でなくなって初めて請求可能なメンバーとしてカウントされます。

前提条件

  • グループのオーナー（Owner）ロールが割り当てられている必要があります。

ユーザー上限を超えたため保留になっているメンバーを承認するには：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 左側のサイドバーで、「設定」>「利用クォータ」を選択します。
  3. 座席]タブのアラートの下にある[保留中の承認者を表示]を選択します。
  4. 承認する各メンバーについて、[承認する] を選択します。

既知のイシュー

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

グループ、サブグループ、またはプロジェクトが外部で共有されるときにユーザー・キャップが適用されるようにするには、トップレベル・ネームスペース内でのみグループの共有を制限します。これにより、同じトップレベル・ネームスペース内のグループを確実に招待できるようになり、グループが共有されたときに新しいユーザー（シート）が追加されるのを防ぐことができます。

ユーザー上限は、ユーザーが課金対象かどうかを考慮しません（例：Ultimateの無料ゲストユーザー）。言い換えると、上限を500に設定した場合、ユーザーキャップは、それらのユーザーがすべて有料シートを消費しているかどうかに関係なく、500ユーザー以降の新規サインアップをブロックします。

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

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

テンプレートソースとして選択できるのは、グループ内のプロジェクトのみです。 これには、グループと共有しているプロジェクトは含まれますが、設定中のグループのサブグループや親グループのプロジェクトは含まれません。

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

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

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

グループ・ファイル・テンプレートの有効化

グループ・ファイル・テンプレートを有効にします：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. テンプレート」セクションを展開します。
  4. テンプレートリポジトリとして機能するプロジェクトを選択します。
  5. 変更を保存を選択します。

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

GitLab 15.9 で導入された フラグ名support_group_level_merge_checks_setting。デフォルトでは無効です。

フラグ: セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。利用可能にするには、管理者がsupport_group_level_merge_checks_settingという機能フラグを有効にします。GitLab.comでは、この機能は利用できません。

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

設定がサブグループまたはプロジェクトに継承された場合、その設定を継承したサブグループまたはプロジェクトでは変更できません。

マージに成功したパイプラインが必要です。

グループ内のすべての子プロジェクトで、マージ前にパイプラインの完了と正常終了を要求するように設定できます。

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

前提条件：

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

この設定を有効にするには

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. マージリクエストを展開します。
  4. マージチェック] で、[パイプラインは成功する必要があります] を選択します。この設定はパイプラインがない場合にマージリクエストがマージされることも防ぎます。
  5. 変更を保存を選択します。

パイプラインをスキップした後のマージを許可します。

スキップされたパイプラインがマージリクエストを防ぐように設定できます。

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

前提条件

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

この動作を変更するには

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. マージリクエストを展開します。
  4. マージチェック] を選択します：
    • パイプラインは成功する必要があります。
    • 選択スキップされたパイプラインは成功とみなされます。
  5. 変更を保存を選択します。

すべてのスレッドが解決されない限りマージしないようにします。

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

前提条件

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

この設定を有効にするには

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. マージリクエストを展開します。
  4. マージチェック] で、[すべてのスレッドを解決する必要があります] を選択します。
  5. 変更を保存を選択します。

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

グループ承認者設定は、トップレベルグループ内の全てのプロジェクトのマージリクエスト承認設定を管理します。これらの設定は、グループに属する全てのプロジェクトにカスケードされます。

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

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. マージリクエスト承認者セクションを展開します。
  4. 必要な設定を選択します。
  5. 変更を保存を選択します。

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

コードサジェストの有効化

  • GitLab 15.11 で導入。
  • 16.0でGitLab UltimateからGitLab Premiumに移行。
  • 16.0でGitLab PremiumからGitLab Freeに移行しました。
caution
この機能はベータ版です。ベータユーザーの方は既知の制限事項をお読みください。フィードバックをお待ちしています。

グループとそのサブグループのすべてのユーザーにコードサジェストへのアクセス権を与えることができます。

グループでコードサジェストを有効にするには、次の手順に従います：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 権限とグループ機能] を展開します。
  4. コードサジェスチョン] で、[このグループのプロジェクトはコードサジェスチョンを使用できます] チェックボックスをオンにします。
  5. 変更を保存を選択します。

エクスペリメント機能の有効化

GitLab 16.0 で導入されました。

caution
実験機能は予期せぬ結果をもたらすかもしれません（例えば、結果は低品質、不完全、支離滅裂、不快、無神経で、安全でないコードや失敗したパイプラインを含むかもしれません）。

最上位グループに属するすべてのユーザーに、エクスペリメント機能へのアクセス権を与えることができます。この設定は、グループに属するすべてのプロジェクトにカスケードされます。

トップレベルグループのExperiment機能を有効にするには：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 権限とグループ機能] を展開します。
  4. Experiment features（エクスペリメント機能）で、Use Experiment features（エクスペリメント機能を使用する）チェックボックスを選択します。
  5. 変更を保存を選択します。

サードパーティのAI機能を有効にします。

GitLab 16.0 で導入されました。

caution
これらのAI機能はサードパーティのサービスを使用し、個人情報を含むデータの送信を必要とします。

グループ内のすべてのユーザーは、サードパーティのAI機能がデフォルトで有効になっています。この設定は、グループに属するすべてのプロジェクトに適用されます。

グループのサードパーティAI機能を無効にするには

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 権限とグループ機能] を展開します。
  4. サードパーティのAIサービス]で、[サードパーティのAIサービスを使用する]チェックボックスをオフにします。
  5. 変更を保存を選択します。

コードサジェスチョンを有効または無効にすると、監査イベントが作成されます。

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

GitLab 12.10からベータ機能として導入されました。

グループに対して、過去90日間に作成されたマージリクエスト、イシュー、メンバーの数を見ることができます。

これらのグループアクティビティ分析は、group_activity_analytics 機能フラグで有効にできます。

Recent Group Activity

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

グループの活動を見る

グループ内で最近行われたアクションをブラウザまたはRSSフィードで見ることができます：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 左サイドバーで「管理」>「アクティビティ」を選択します。

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