Chapters ▾ 2nd Edition

4.8 Gitサーバー - GitLab

GitLab

前節で紹介した GitWeb はとてもシンプルでした。 もし、もっとモダンで高機能な Git サーバーが必要な場合には、他のオープンソース・ソフトウェアが選択肢になるでしょう。 それらのなかでも GitLab はよく使われていますので、一例として紹介します。 GitWeb よりも複雑でメンテナンスも必要ではありますが、GitLab はより高機能な選択肢です。

インストール

GitLab はデータベースを使用する Web アプリケーションです。そのため、インストール方法は他の Git サーバーより複雑になってしまいます。 とはいえ、幸いなことにドキュメントは充実していて、かつ手順は簡素化されています。

GitLab は数種類の方法でインストールできます。 とりあえず動かしてみるには、仮想マシンのイメージ、もしくはワンクリックインストーラーを使います。 https://bitnami.com/stack/gitlab からそれらのファイルをダウンロード・インストールし、使用する環境に応じて設定を変更しましょう。 この方法では、Bitnami が気を利かせてログイン画面を使えるようにしてくれています（alt-→ と入力すると表示されます）。インストールした GitLab 用の IP アドレス・ユーザー名・パスワードを表示してくれる便利な画面です。

Bitnami GitLab 仮想マシンのログイン画面
図 49. Bitnami GitLab 仮想マシンのログイン画面

その他の方法については、GitLab Community Edition の README を参照してください。 https://gitlab.com/gitlab-org/gitlab-ce/tree/master で確認できます。 そこで紹介されている GitLab のインストール方法には、Chef のレシピを使う方法、Digital Ocean で仮想マシンを用いる方法、RPM や DEB のパッケージを用いる方法（執筆段階ではベータ）などがあります。 その他にも “非公式” のガイドとして、サポート外の OS やデータベースで GitLab を動かす方法、手動でインストールを行うためのスクリプトなど、多くのトピックが紹介されています。

GitLab の管理

GitLab の管理画面はブラウザでアクセスします。 ブラウザを使って GitLab をインストールしたサーバーのホスト名か IP アドレスにアクセスし、管理者としてログインしましょう。 デフォルトのユーザー名は admin@local.host で、デフォルトのパスワードは 5iveL!fe です（この組み合わせでログインすると、パスワードを変更することを最初に促されます）。 ログインしたら、 画面右上のメニューにある “Admin area” のアイコンをクリックしましょう。

GitLab メニューにある ``Admin area'' の項目
図 50. GitLab メニューにある “Admin area” の項目

ユーザー

GitLab におけるユーザーは、使用者に紐付けられたアカウントのことを指します。 それは複雑なものではありません。メインはログイン情報ごとに登録された個人情報です。 また、ユーザーアカウントには 名前空間 が設定されていて、ユーザーが保持するプロジェクトの識別子として用いられます。 たとえば、ユーザー jane が project という名前のプロジェクトを保持していた場合は、そのプロジェクトの URL は http://server/jane/project になります。

GitLab ユーザー管理画面
図 51. GitLab ユーザー管理画面

ユーザーを削除する場合、やり方は2つです。 まずはユーザーを「ブロック」する方法です。この場合、ブロックされたユーザーは GitLab にはログインできなくなります。一方、ユーザーの名前空間配下のデータは削除されず、ユーザーのメールアドレスで署名されたコミットとユーザープロファイルとの関連付けも有効なままになります。

もうひとつのやり方はユーザーを「破壊」する方法です。ユーザーを破壊すると、GitLab のデータベース、ファイルシステムから削除されます。 ユーザーの名前空間配下のデータ・プロジェクトも削除されますし、そのユーザーが作成したグループも同じように削除されます。 この方法は「ブロック」と比べはるかに恒久的でやり直しがきかないものです。よって、使われることはめったにありません。

グループ

GitLab では、複数のプロジェクトをグループとしてまとめられます。そして、グループにはプロジェクトごとのユーザーのアクセス権情報も含まれています。 また、ユーザーの場合と同じように、それぞれのグループには名前空間があります。たとえば、 training グループに materials というプロジェクトがあった場合、URL は http://server/training/materials になります。

GitLab グループ管理画面
図 52. GitLab グループ管理画面

グループにはメンバーを追加できます。さらに、メンバーそれぞれにプロジェクトごとの権限と、グループそのものに対する権限が設定できます。 権限は “Guest” （issues とチャットのみ）から “Owner” （グループと配下のメンバー・プロジェクトの管理権限）までが用意されています。 各権限の詳細は膨大なため省略しますが、管理画面にあるリンクを辿ると確認できるようになっています。

プロジェクト

GitLab のプロジェクトとは、大体の場合ひとつの Git のリポジトリを指します。 なんらかの名前空間（ユーザーかグループ）に、プロジェクトはすべて属しています。 プロジェクトがユーザーの名前空間に属していれば、そのオーナーはアクセス権をすべて管理できます。プロジェクトがグループに属していれば、グループ自体のアクセス権設定がプロジェクトにも引き継がれます。

また、プロジェクトには公開レベル設定があり、どのユーザーにプロジェクトのページとリポジトリの読み込み権限を与えるかを設定できます。 プロジェクトが Private の場合、アクセス権をユーザーごとに明示的に設定する必要があります。 プロジェクトが Internal の場合はログイン済みのユーザーであれば閲覧でき、Public なプロジェクトであれば誰でも閲覧できます。 なお、この設定で、Git の “fetch” コマンドと ウェブ画面の両方のアクセス権が設定されることに注意しましょう。

フック

GitLab はフック（プロジェクト・システムの両方）に対応しています。 どちらのフックであれ、該当のイベントが発生した都度、GitLab のサーバーは JSON データを使って HTTP POST リクエストを発行します。 これは、Git リポジトリや GitLab を開発自動化の仕組みと連携させるときにとても便利です。特に CI サーバー・チャットサービス・デプロイ用のツールなどとの連携に役立つでしょう。

基本的な使い方

GitLab で最初にやるべきことは、新規プロジェクトの作成です。 ツールバーの “+” アイコンをクリックすると作成が始まります。 まず、プロジェクト名称・所属すべき名前空間・公開レベル設定を作成時に入力します。 それらの大半は設定画面からあとから変更可能です。 次に “Create Project” をクリックすれば、プロジェクトが作成されます。

プロジェクトが作成されたら、まずは手元の Git リポジトリとそのプロジェクトを関連付けるとよいでしょう。 プロジェクトにアクセスするには HTTPS か SSH を使います。いずれも、Git のリモートとして設定可能なプロトコルです。 設定用の URL は、プロジェクトのページの最上部に表示されています。

$ git remote add gitlab https://server/namespace/project.git

手元に Git リポジトリがない場合は、以下のようにしてリモートからクローンしましょう。

$ git clone https://server/namespace/project.git

GitLab の ウェブ画面には、リポジトリの情報を確認する便利な画面がいくつもあります。 プロジェクトのトップページでは最近の行動履歴が確認できますし、画面上部にあるリンクをたどるとファイル一覧やコミットログを確認できます。

共同作業

GitLab でホストしているプロジェクトで共同作業を行うもっともシンプルな方法は、Git リポジトリへのプッシュアクセス権を相手に与えてしまうことです。 ユーザーをプロジェクトに追加するには、プロジェクトの設定画面にある “Members” のセクションを使います。新規ユーザーにアクセス権を設定するのにも同じセクションを使います（アクセス権の詳細については、 グループ でも少し触れました）。 ユーザーに付与された権限が “Developer” かそれ以上であれば、リポジトリへコミットやブランチを問題なく直接プッシュできます。

もうひとつ、より疎結合な共同作業の方法があります。マージリクエストです。 この機能を使えば、任意のユーザー（プロジェクトを閲覧可能なユーザーに限られます）に所定の方法で共同作業に参加してもらえます。 まず、リポジトリに直接プッシュする権限のあるユーザーの場合は、ブランチを作ってコミットをプッシュしたうえで、そのブランチから master など希望するブランチに向けてマージリクエストを作成します。 一方、プッシュ権限のないユーザーの場合、まずはリポジトリを「フォーク」（自分専用のコピーを作成）します。続いて その コピーにコミットをプッシュしたら、コピーから本家に向けてマージリクエストを作成しましょう。 この方法を使えば、どんな変更がいつリポジトリに追加されるかを管理者が管理しつつ、任意のユーザーに共同作業に参加してもらえます。

GitLab においては、マージリクエストや issue を使って議論を深めていきます。 マージリクエストは、変更内容について行ごとに議論すること（簡易的なコードレビュー機能としても使えます）にも使えますし、マージリクエスト全体についての議論のスレッドとしても使えます。 また、マージリクエストや issue には担当者を設定できますし、マイルストーンの一部にもなります。

この節では主に GitLab の Git 関連部分を見てきました。ただ、GitLab はとても完成度の高いシステムで、共同作業に役立つ機能は他にもたくさんあります。たとえば、プロジェクト用の wiki やシステム管理ツールなどです。 最後に GitLab の利点としてもう一点挙げておきましょう。GitLab は、一度セットアップが終わってサーバーが動き出せば、設定ファイルをいじったりサーバーに SSH でログインしたりする必要はほとんどありません。管理作業、そして通常利用の大半は、ブラウザ画面から操作できます。