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割離れた気がする…。
読みやすく且つ初心者にとっつきやすい記事を心掛けていたというのに、既にそれが実現できていないような気がしなくもないですが、今回も頑張ります。

本記事の対象の方
今回のブログのゴール
このブログをお読みいただくにあたっての事前ご連絡事項
Step1. プロジェクトを作成する場所を考える
Step2. 空のプロジェクトを作るユーザーを考える
Step3. いよいよ空のプロジェクトを作る
【おまけ】プロジェクト作成画面で "リポジトリを初期化してREADMEファイルを作成する" にチェック入れたのに、READMEが生成されなかった場合
最後に

本記事の対象の方

こちらのブログでGitLabにグループの作成とメンバーの追加を実施し、次のアクションを求めている方。
GitLabにおいてプロジェクト作成可能なロールの指定方法の情報を探している方。
GitLabの Default branch と Protected 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 における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。

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

プロジェクトを作成する場所を考えましょう。

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

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

Personal Namespaceって？

簡単に申し上げると、そのユーザーが作成された時に自動で作成されるユーザー専用のNamespaceです。
参考：Namespaces | 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 - Projects limit for a user | GitLab

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

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

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

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

次に誰でプロジェクトを作るか考えます。

少なくとも、グループやサブグループにプロジェクトを作るときは、そのグループ (またはサブグループで) でプロジェクト作成権限を持っている必要があります。
逆にPersonal Namespaceに作る場合は、プロジェクト作成権限を持っているので気にせず進めてOKです！

先に宣言しておきます。本記事では、任意に作成した可視性レベル "プライベート" のグループにロール "Maintainers" を持つユーザーで後続の手順を進めます。
可視性レベルについてはこちらの記事で言及しておりますので、もし可視性レベルについてご存じなければご参照いただければと存じます。

で。早速プロジェクトを作りたい。
作りたいのですが…GitLabをご利用いただくにあたり、ご理解いただく必要がある仕様 (機能？) があります…。
それは "Protected branches" と "デフォルトブランチ" についてです。

この後、グループにおけるプロジェクト作成権限と、Protected branches、デフォルトブランチについて延々と説明します。
「そういうのどうでもいいから、早くMaintainersロールのユーザー使ってプロジェクト作りたい。」という方はStep3. いよいよ空のプロジェクトを作るからお読みください。

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

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

具体的には、対象グループの[設定]>[一般]>[パーミッション、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になっているのかは、プロジェクト画面から[リポジトリ]>[ブランチ]から確認することができます。
この一覧で [保護] というマークがついているブランチが Protected branches です。
下図はブランチ"main" と "aaa01" がProtected branchesの対象となっていて、他 "bbb01" と "ccc01" は対象となっていません。
このうち "main” はデフォルトブランチなので自動的にProtected branchesの対象となります。"aaa01" は私が任意でProtected branchesに追加したブランチです。

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

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

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

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

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

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

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

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

先述の通りGitLabのデフォルトブランチ名は14.0以降なら "main" 、14.0より前なら "master" が初期値として設定されていますが、これらを変更することも可能です。

個々のプロジェクトにおいてデフォルトのブランチ名を変更することも、グループ単位、インスタンス単位 (GitLab環境単位) でデフォルトブランチ名を変更することも可能です。
手順については以下のGitLab Docksをご参照ください。
参考：Default branch - Change the default branch name for a project | GitLab

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

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

プロジェクトを作る場所と、作るユーザーを決めたら、さっそく空のプロジェクトを作りましょう。
ここまでくる道のりがやたら長かった…。

ここでは例として、検証用に作成したグループ "PrivateGroup01" にロール Maintainers のユーザーで作成しますが、作る場所とユーザーは前述した内容を参考に各自ご検討ください。

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

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

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

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

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

各項目を設定します。

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

今回は空のプロジェクトを作成するだけなので、他はとりあえず全部デフォルトで進みます。
設定が終わったら[プロジェクトを作成]をクリックします。

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

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

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

プロジェクト作成画面で "リポジトリを初期化してREADMEファイルを作成する" にチェック入れたのに、READMEファイルが生成されず、デフォルトブランチ "main" も生成されなかった場合につきまして。

おそらくですが、プロジェクトの作成を実行したユーザーが、プロジェクトを作成したNamespaceに対して Developers のロールを持っているユーザーである可能性があります。

これは既知の事象で、Protected branchesの機能の影響によりこれが発生します。
参考：Protected branches - Who can modify a protected branch | GitLab

GitLabが壊れたとかではなく、正常にプロジェクト自体は作成されています。
権限を有するユーザーでブランチを作成していけば普通に使えるのでご安心ください。

最後に

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

今回のゴール

保護されたブランチ (Protected Branch) とデフォルトブランチの概要を理解する。
プロジェクト作成可能なロールを理解する。
空のプロジェクトを作成する。
(おまけ) GitLabにおける Namespace と Personal Namespace の概要を理解する。

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

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

今までのGitLabの検証ブログはこちらです。