• 概要
• サブグループの作成
• メンバーシップ
  • 祖先グループのメンバーシップのオーバーライド
• サブグループについて
• 制限事項

サブグループ

GitLab 9.0で導入されました。

GitLabは最大20レベルのサブグループをサポートしており、ネストされたグループや階層グループとも呼ばれています。

サブグループを使うことで、以下のことが可能になります：

• 内部組織と外部組織の分離各グループは独自の可視性レベルを持つことができるため、同じ傘の下で異なる目的のグループをホストすることができます。
• 大規模プロジェクトの整理：大規模プロジェクトでは、サブグループによってソースコードの一部の権限を分けることが容易になる可能性があります。
• グループメンバーによって異なる権限を与えることで、グループメンバーの管理と可視性の管理を容易にします。

グループおよびプロジェクトで許可される権限の詳細については、可視性レベルを参照してください。

概要

グループはその中に多くのサブグループを持つことができ、同時に1つのグループには1つの直接の親グループしか持つことができません。 これはディレクトリの動作やネストされたアイテムリストに似ています：

• グループ1
  • グループ1.1
  • グループ1.2
    • グループ1.2.1
    • グループ1.2.2
      • グループ1.2.2.1

実際の例では、GNU/Linuxディストリビューションをメンテナーとして、最初のグループがディストリビューションの名前で、それ以降のグループは以下のように分割されるとします：

• 組織グループ - GNU/Linuxディストロ
  • カテゴリサブグループ - パッケージ
    • (プロジェクト) Package01
    • (プロジェクト) Package02
  • カテゴリー別サブグループ - ソフトウェア
    • (プロジェクト） Core
    • (プロジェクト）CLI
    • (プロジェクト）Androidアプリ
    • (プロジェクト）iOSアプリ
  • カテゴリー別サブグループ - インフラツール
    • (プロジェクト）Ansibleプレイブック

企業としてのGitLabのもう一つの例は次のようなものです：

• 組織グループ - GitLab
  • カテゴリー別サブグループ - マーケティング
    • (プロジェクト）デザイン
    • (プロジェクト）全般
  • カテゴリー別サブグループ - ソフトウェア
    • (プロジェクト）GitLab CE
    • (プロジェクト）GitLab EE
    • (プロジェクト） Omnibus GitLab
    • (プロジェクト）GitLab Runner
    • (プロジェクト）GitLab Pagesデーモン
  • カテゴリー別サブグループ - インフラツール
    • (プロジェクト）シェフの料理本
  • カテゴリー・サブグループ - エグゼクティブ・チーム

サブグループ間でプロジェクトの転送やインポートなどのアクションを実行する場合の動作は、group/project レベルでこれらのアクションを実行する場合と同じです。

サブグループの作成

サブグループを作成するには、グループの設定に応じて、そのグループのオーナーかメンテナーである必要があります。

で作成されたグループがデフォルトで使用されます：

• GitLab 12.2以降では、オーナーとメンテナーの両方がサブグループを作成できます。
• GitLab 12.1以前では、オーナーがサブグループを作成することしかできません。

この設定は、オーナーまたは管理者がどのグループに対しても行うことができます。

グループ名として使用できない単語のリストについては、予約名を参照してください。

管理者の設定でグループ作成が無効になっている場合でも、直属の親グループにオーナー（またはメンテナー）として明示的に追加されていれば、ユーザーは常にサブグループを作成できます。

サブグループを作成するには

1. グループのダッシュボードで新規プロジェクト分割ボタンを展開し、新規サブグループを選択して新規サブグループボタンをクリックします。

   

2. グループ・パスの下に直接の親グループのネームスペースが固定されていることに注意してください。 可視レベルは、直接の親グループとは異なる場合があります。

   

3. グループの作成ボタンをクリックすると、新しいグループのダッシュボードページに移動します。

以降のグループも同じ手順で作成します。

メンバーシップ

サブグループにメンバーを追加すると、そのメンバーは親グループのメンバシップと権限レベルを継承します。 このモデルでは、親グループのいずれかのメンバシップを持っていれば、ネストしたグループへのアクセスが可能です。

サブグループのパイプラインのジョブは、親グループに登録されたランナーを使用できます。 これは、親グループ用に設定されたシークレットがサブグループのジョブでも使用できることを意味します。

さらに、サブグループに所属するプロジェクトのメンテナーは、親グループに登録されているRunnerの詳細を見ることができます。

メンバーのグループ権限はオーナーだけが変更でき、メンバーが追加されたグループのメンバーページでのみ変更できます。

メンバーが親グループから権限を継承しているかどうかは、グループの「メンバー」ページを見ればわかります。

上の画像から次のことが推測できます：

• グループfourにアクセスできるメンバーは5人。
• User0はレポーターであり、グループfourの上位階層にあるグループoneから権限を継承しています。
• User1 は開発者であり、グループfourの上位階層にあるグループone/two から権限を継承しています。
• User2 は開発者であり、グループfourの上位階層にあるグループone/two/three から権限を継承しています。
• User3は、親グループの表示がないため、fourのグループに属しています。
• Administratorはオーナーであり、すべてのサブグループのメンバーです。そのため、User3と同様、祖先グループの表示はありません。

GitLab 12.6からは、右側のドロップダウンを使ってこのリストをフィルタリングすることができます：

• Show only direct membersは、AdministratorとUser3のみを表示します。これらのユーザーは、fourのグループに属する唯一のユーザーだからです。
• User0、User1、User2のどのグループが継承された権限であっても、継承されたメンバーのみを表示します。

祖先グループのメンバーシップのオーバーライド

ユーザーの先祖グループ（最初に追加されたグループ）のメンバーシップをオーバーライドするには、ユーザーをより高い権限で新しいサブグループに追加します。

例えば、User0が最初にgroup-1/group-1-1 Developer権限で group-1/group-1-1グループに追加された場合、その権限をgroup-1/group-1-1.NETの他のすべてのサブグループで継承 group-1/group-1-1します。 User0にメンテナー権限を与えるには、group-1/group-1-1/group1-1-1、そのグループにメンテナーとして再度追加します。 そのグループからUser0を削除すると、権限は祖先グループのものにフォールバックします。

サブグループについて

イシューやコミット、マージリクエストでグループ (@group) に言及すると、そのグループの全メンバーに通知されました。 サブグループを使用することで、グループの構造を分割したい場合に、よりきめ細かく対応できるようになりました。 言及は以前と同じように機能し、通知するグループを選択できます。

制限事項

サブグループでできないことのリストです：

• GitLabPages はサブグループの下でホストされているプロジェクトをサポートしていますが、サブグループのウェブサイトはサポートしていません。 つまり、サブグループの下にプロジェクトのウェブサイトを持つことはできますが、グループのウェブサイトをサポートしているのは最上位のグループだけです。
• プロジェクトが所属しているグループの祖先にあたるグループとプロジェクトを共有することはできません。 つまり、階層を下るにつれてしか共有することができません。例えば、group/subgroup01/project はgroupと共有することはできませんが、group/subgroup02 やgroup/subgroup01/subgroup03と共有することはできます。