株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

GitとCI/CDに関する知識ゼロのSEが、GitLabでProtected branchesとNamespaceについて勉強しながらプロジェクト作るだけの記事

2022/05/06 少しでも見やすく…と思い、ブログのスタイルを一部更新致しました。
2022/05/20 GitLabのデモ動画を作りました!このブログの末尾にリンクを張ったのでよろしければご視聴ください。 

皆様こんにちは。普段はセキュリティ商材を担当しているSEの小池と申します。

私の普段の業務はGitやCI/CDに無縁なのですが、会社から頂戴した「GitLabの技術ブログ書いておいて」というミッションを達成すべく、今回も頑張ってGitLabの技術をちまちま習得してまいります。
今回はGitLabのProtected BrancheとNamespaceに関するうんちくが9割、手を動かしてプロジェクト作成する作業が1割ですあぁ、この一言で読者が3割離れた気がする…。
読みやすく 且つ 初心者にとっつきやすい記事を心掛けていたというのに、既にそれが実現できていないような気がしなくもないですが、今回も頑張ります。

このブログの内容は以下の通りです。

本記事の対象の方

  • こちらのブログでGitLabにグループの作成とメンバーの追加を実施し、次のアクションを求めている方。
  • GitLabにおいてプロジェクト作成可能なロールの指定方法の情報を探している方。
  • GitLabの Default branchProtected branches について情報収集なさっている方。
  • GitLabの Personal Namespace について情報収集なさっている方。
  • GitLabで"Create Project" からREADMEを自動生成するオプションでプロジェクト作ったが、ReadMe.md が生成されておらず「?」となっていらっしゃる方。

今回のブログのゴール

このブログのゴールはこちらです!

このブログのゴール
  • プロジェクト作成可能なロール、保護されたブランチ (Protected Branch) 、デフォルトブランチの概要を理解する。
  • 空のプロジェクトを作成する。
  • (余裕があれば) GitLabにおける Namespace と Personal Namespace について、そういうものがあるんだな程度に理解する。

このブログをお読みいただくにあたっての事前ご連絡事項

  • 本記事はGitLabがどういった製品なのかの説明はしておりません。製品説明につきましては弊社の製品ページ (こちら) をご参照ください。
  • 本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。
  • 本記事はこちらのGitLabに関するブログの続きを想定しており、既に1つ以上のグループがあり、そこにメンバーの追加済みであることを想定しております。
  • 本記事は GitLab Enterprise Edition 14.6.1-ee における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。

①プロジェクトを作成する場所を考える

プロジェクトを作成する場所を考えましょう
GitLabにてプロジェクトを作成する場合は、Personal Namespace か グループ配下 (グループのNamespace) のどちらかに作成することになります
先に宣言しておきますが、このブログではカスタムで作成したグループ配下に作成します
GitLabにおけるグループとは何か?の説明は前回のこちらのブログに頑張って書きましたので、もしグループの概念が分からない方はご参照ください。

この後しばらくPersonal Namespaceとは何か~という話をしますが、「そういうのどうでもいいから、さっさと次進みたい。」という方は②空のプロジェクトを作るユーザーを考える へお進みください。

Personal Namespaceって?

簡単に申し上げると、そのユーザーが作成された時に自動で作成されるユーザー専用のNamespaceです。
Groups | GitLab

イメージ図で説明します。例えば株式会社A用のGitLab環境があるとします。

ここにグループ "group01" を作成します。すると、Namespace https://samplegitlab.example.com/group01 が作成されます。

次に、サブグループ "subgroup01" をグループ "group01" 配下に作成します。
するとサブグループのNamespace https://samplegitlab.example.com/group01/subgroup01 が作成されます。
このようにグループおよびサブグループを作成すると、対応するNamespaceが作成されます。

この環境にユーザー "user01" を新規作成します。この時、自動でPersonal Namespace https://samplegitlab.example.com/user01 が作成されます。
このユーザーを作成した際に自動で作成されるNamespaceが、GitLab DocsなどでPersonal Namespaceと表現されるものになります

GitLabでプロジェクトを作成する場合、それらはグループやサブグループのNamespaceか、Personal Namespaceに作成することになります。
GitLabの環境直下にプロジェクトを直接作成することはできません。

グループのNamespaceとPersonal Namespaceの違いは?

運用でも意識すべきと思われる違いをいくつか挙げます。
まず、サブグループの作成可否の違いがあります。
通常のグループのNamespaceにはサブグループを作成できますが、Personal Namespaceにはサブグループを作成できません

次に、URLにブラウザでアクセスすると、通常のグループのNamespaceとPersonal Namespaceでは表示が異なります
通常のグループのNamespaceのURLにブラウザでアクセスするとこのような画面になります。
(この画面は私が適当に作ったGitLab検証環境にある グループ "privategroup01" の例です。)

Personal NamespaceのURLにブラウザでアクセスするとこのような画面になります。
(この画面は私が適当に作ったGitLab検証環境にある ユーザー "dev02" の例です。)
前掲致しましたグループのGuiとは大きく異なり、Personal NamespaceのURLのGuiからでは設定、エピック、Wiki、パッケージとレジストリの管理、イシューボードなどを利用できません。

最後に、他のメンバーの招待 (Invite) の可否 と 継承について。
グループおよびサブグループの場合、そのグループ 及び サブグループ自身にメンバーを招待することができますが、Personal Namespaceの場合はそこへ直接メンバーを招待することができません。
したがって、Personal Namespaceの場合は、配下に作成したプロジェクトに直接メンバーを招待する必要があります。
なお、前回の記事 (こちら) で言及した通り、グループのメンバーは配下のサブグループ 及び プロジェクトに対して親グループで持っていたロールを自動で継承し、サブグループのメンバーは配下のプロジェクトに対してサブグループで持っていたロールを自動で継承します。
正直自分で書いていてわけわかんなくなってきましたが、要するにこんな感じです。

おそらくこれ以外にも大量に違いがあるのですが、ご紹介はこのくらいに致します。
ひとまず、ユーザーごとに存在するPersonal NamespaceとグループおよびサブグループのNamespaceは、似て非なるものであるということだけご理解いただければと存じます。

Personal Namespaceに作成できるプロジェクトの数の制限

話がどんどんブログの目的から離れていくな…と思いつつ、Personal Namespaceに作成できるプロジェクトの数の制限について述べます。
これはユーザー依存の設定値 "Personal projects limit" で設定でき、デフォルトだと100,000となっています。
後から変更することも可能です。
Account and limit settings | GitLab

毎回ユーザーを作成するたびに "Personal projects limit" の値を変更するのが面倒な場合は、環境のデフォルト値ごと変えるのが便利かと存じます。
GitLab環境におけるデフォルトの "Personal projects limit" を変更するには、GitLab管理者で [Menu]>[Admin]>[設定]>[一般]>[アカウントと制限]>[Default projects limit]の値を変更してください。
Account and limit settings | GitLab

なお、これらの設定はあくまでPersonal Namespaceに作成できるプロジェクトの数の制限です。
この設定は、任意のグループ 及び サブグループに作成しているプロジェクトの数には影響しません。

Personal Namespaceに関する説明は以上です。

②空のプロジェクトを作るユーザーを考える

次に誰でプロジェクトを作るか考えます
少なくとも、グループやサブグループにプロジェクトを作るときは、そのグループ (またはサブグループで) でプロジェクト作成権限を持っている必要があります。
逆にPersonal Namespaceに作る場合は、プロジェクト作成権限を持っているので気にせず進めてOKです!
先に宣言しておきます。本記事では、任意に作成した可視性レベル "プライベート" のグループにロール "Maintainers" を持つユーザーで後続の手順を進めます
可視性レベルについてはこちらの記事で言及しておりますので、もし可視性レベルについてご存じなければご参照いただければと存じます。

で。早速プロジェクトを作りたい。
作りたいのですが…GitLabをご利用いただくにあたり、ご理解いただく必要がある仕様 (機能?) があります…。
それは "Protected branches""デフォルトブランチ" についてです。
この後、グループにおけるプロジェクト作成権限と、Protected branches、デフォルトブランチについて延々と説明します。
「そういうのどうでもいいから、早くMaintainersロールのユーザー使ってプロジェクト作りたい。」という方は③いよいよ空のプロジェクトを作るからお読みください。

グループにおけるプロジェクト作成権限

グループに属するメンバーはロールが割りてられます。
グループでは 何のロールにプロジェクトの作成を許可するか を設定することができます。

具体的には、対象グループの[設定]>[一般]>[パーミッション、LFS、2FA]>[プロジェクトの作成を許可する]で指定できます。
本設定項目はデフォルトでは "Developers + Maintainers" になっています。
仮のデフォルト値の設定であった場合、このグループでプロジェクトが作成できるユーザーは、Developers, Maintainers, Ownerのいずれかのロールを持つユーザー、もしくはGitLab管理者となります。

Protected branchesって?

Protected branchesを簡単に言うと、特定のブランチに対して、プッシュ、強制プッシュ、ブランチの削除 等を実行可能なユーザーを制限する機能です。
Protected branches | GitLab

Protected branchesによって制限されるアクションは?

具体的に制限されるアクションは以下の通りです。

  • マージの許可 (ロールで指定)
  • プッシュの許可 (ロールで指定)
  • 強制的なプッシュの許可 (ON/OFFの設定可)
  • マージリクエストによるマージに際し、CODEOWNERSによる承認が必要 (ON/OFFの設定可)
  • 本ブランチの削除を禁止する

上記のうち、CODEOWNERSについてはPremium限定機能です。
Code Owners | GitLab

プロジェクトの[設定]>[リポジトリ]>[Protected branch]から設定の確認 及び 変更ができます。

Protected branchesの対象となるブランチは?

GitLabのデフォルトの設定では、そのリポジトリのデフォルトのブランチがProtected branchesの対象となります
そのほか、自分でそのリポジトリにある別のブランチを任意でProtected branchesに追加することも可能です。

現在どのブランチがProtected branchesになっているのかは、プロジェクト画面から[リポジトリ]>[ブランチ]から確認することができます。
下図はブランチ"main" と "aaa01" がProtected branchesの対象となっていて、他 "bbb01" と "ccc01" は対象となっていません。
このうち "main” はデフォルトブランチなので自動的にProtected branchesの対象となります。"aaa01" は私が任意でProtected branchesに追加したブランチです。

デフォルトブランチって何?

デフォルトブランチはそのリポジトリで1つだけ指定できる特別なブランチで、他のブランチとは異なる構成オプションがあります
Default branch | GitLab

具体的には、まずデフォルトブランチは削除できません。
次に、強制的なプッシュ実行を実行できません。
また、前述致しました通り、デフォルトブランチは自動的にProtected branchesの対象になります。
他の効果についてはGitLab Docsをご参照ください。
Default branch | GitLab
ただし、"強制的なプッシュを実行できない" のは、デフォルトブランチがProtected branchesになっているからであり、これは変更することが可能です。

基本的に、プロジェクトのリポジトリに最初に作成したブランチがデフォルトブランチになります
GitLabで新規作成したリポジトリにおいて、最初のブランチ (デフォルトブランチになるブランチ) のデフォルト名はバージョンによって異なりますが、基本的に14.0以降は "main" 、それより前は "master" となります。
後で別のブランチをデフォルトブランチに変更することも可能です。
他のリポジトリをインポートしたり、テンプレートを用いた場合は、インポート元リポジトリ (もしくはテンプレート) でデフォルトブランチとなっていたブランチが、GitLabでもデフォルトブランチになります。

現在のリポジトリでどれがデフォルトブランチなのかを確認するには、プロジェクト画面から[リポジトリ]>[ブランチ]から確認することができます。

デフォルトブランチの変更は可能か?

リポジトリのデフォルトブランチを変更したい場合は、プロジェクトの[設定]>[リポジトリ]>[デフォルトブランチ]から変更できます。

デフォルトのブランチ名の初期値は変更できる?

先述の通りGitLabのデフォルトブランチ名は14.0以降なら "main" 、14.0より前なら "master" が初期値として設定されていますが、これらを変更することも可能です。
個々のプロジェクトにおいてデフォルトのブランチ名を変更することも、グループ単位、インスタンス単位 (GitLab環境単位) でデフォルトブランチ名を変更することも可能です。
手順については以下のGitLab Docksをご参照ください。
Default branch | GitLab

以上、プロジェクト作成権限、Protected branches、デフォルトブランチについて延々とうんちくを述べました。

③いよいよ空のプロジェクトを作る

プロジェクトを作る場所と、作るユーザーを決めたら、さっそく空のプロジェクトを作りましょうここまでくる道のりがやたら長かった…。
ここでは例として、検証用に作成したグループ "PrivateGroup01" に ロール Maintainers のユーザーで作成しますが、作る場所とユーザーは前述した内容を参考に各自ご検討ください。

  • グループ:PrivateGroup01 (プライベート)
  • ユーザー:maintener01 (PrivateGroup01のメンバー。ロール "Maintainers" 。)

まずは作業するユーザーでサインインします。
[Menu]>[Groups]>[所属グループ]をクリックします。

プロジェクトを作成するグループ名をクリックします。
ここでは例として [PrivateGroup01] をクリックします。

[新規プロジェクト]をクリックします。

今回は新規作成したいので [Create blank project] をクリックします。
Manage projects | GitLab

各項目を設定します。

  • プロジェクト名: このプロジェクト名です。
  • プロジェクトの説明(オプション): 日本語も一応行ける模様なので、試しに日本語文字列を設定してみました。
  • 可視性レベル: 任意に選択します。親グループの可視性レベル以下しか設定できません。今回のように親グループがプライベートの場合は、必然的にプライベート一択になります。

他はとりあえず全部デフォルトで進みます。
なぜなら筆者はGitとかCI/CDとかよくわかっていないからです!
設定が終わったら[プロジェクトを作成]をクリックします。

空のプロジェクトが作成されました。
デフォルトブランチである "main" ブランチが作成されていること、READMEが作成されていることをご確認ください。

以上で空のプロジェクトの作成は完了です。

【おまけ】プロジェクト作成画面で "リポジトリを初期化してREADMEファイルを作成する" にチェック入れたのに、READMEが生成されなかった場合

プロジェクト作成画面で "リポジトリを初期化してREADMEファイルを作成する" にチェック入れたのに、READMEファイルが生成されず、デフォルトブランチ "main" も生成されなかった場合につきまして。
おそらくですが、プロジェクトの作成を実行したユーザーが、プロジェクトを作成したNamespaceに対して Developers のロールを持っているユーザーである可能性があります。


これは既知の事象で、Protected branchesの機能の影響によりこれが発生します。
Protected branches | GitLab
GitLabが壊れたとかではなく、正常にプロジェクト自体は作成されています。 権限を有するユーザーでブランチを作成していけば普通に使えるのでご安心ください。

最後に

この度はGitもCI/CDもよくわかっていないど素人SEによるGitLab検証ブログをお読みいただき、誠にありがとうございます。
このブログの目標は以下のとおりでしたが、皆さまはいかがでしたでしょうか。

このブログのゴール
  • プロジェクト作成可能なロール、保護されたブランチ (Protected Branch) 、デフォルトブランチの概要を理解する。
  • 空のプロジェクトを作成する。
  • (余裕があれば) GitLabにおける Namespace と Personal Namespace について、そういうものがあるんだな程度に理解する。

今回はGitLabを運用する方なら1回は調べなきゃいけないような仕様の説明と、それらを考慮した上で空のプロジェクトを作成しました。
本当はGit機能をお試しするところまで書こうと思ったのですが、今回は仕様説明が盛りだくさんになってしまったので諦めました。
今回はちょっと説明が多くなってしまったので、次回以降はGitLabの仕様を理解せずともとりあえず製品を触る方針に戻していこうと思います・・・。
この記事が「なんかよくわからんけどGitLabをとりあえず触りたい!」という方のお力になれば幸甚にございます。


GitLabに関するお問い合わせは、以下のフォームからお願い致します。
GitLab製品 お問い合わせ

2022/05/20追記
GitLab操作デモ動画 (基本編) を作っちゃいました。
つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。

www.youtube.com