[[313385]]

Gitoliteを使えば、Gitを使ってGitサーバーを管理できます。Gitのあまり知られていない使い方については、こちらの記事シリーズで詳しく解説しています。

このシリーズの記事で紹介してきたように、Gitはソースコードを追跡するだけでなく、もっと多くのことができます。信じられないかもしれませんが、GitはGitサーバーの管理さえできるので、Git自体を使ってある程度Gitサーバーを運用することも可能です。

もちろん、これにはGitの日常的な使用以外にも多くの要素が関係しますが、その中で最も重要なのはGitoliteです。これは、Gitの使用状況を細部まで管理するバックエンドアプリケーションです。Gitoliteの利点は、Gitをフロントエンドインターフェースとして使用しているため、Gitサーバー管理を他のGitベースのワークフローに簡単に統合できることです。Gitoliteは、サーバー上の特定のリポジトリにアクセスできるユーザーとその権限を正確に制御できます。通常のLinuxシステムツールを使用してこれを自分で管理することもできますが、複数のユーザーと複数のリポジトリがある場合は、かなりの作業量が必要になります。

Gitolite の開発者は、多くのユーザーに環境全体へのアクセスを許可することなく Git サーバーへのアクセスを簡単に提供できるようにするために多くの作業を行ってきました。そして、これらすべてを Git で実現できます。

Gitoliteはグラフィカルな管理者パネルやユーザーパネルではありません。優れたGiteaプロジェクトでは同様の機能を提供していますが、この記事ではGitoliteのシンプルさ、洗練さ、そして使い慣れた操作性に焦点を当てます。

Gitoliteをインストールする

GitサーバーがLinux上で動作している場合、パッケージマネージャー（CentOSとRHELではyum 、DebianとUbuntuではapt 、OpenSUSEではzypperなど）を使ってGitoliteをインストールできます。例えば、RHELでは以下のようになります。

 $ sudo yum install gitolite3

多くのディストリビューションでは、リポジトリに Gitolite の古いバージョンがまだ提供されていますが、最新バージョンはバージョン 3 です。

サーバーへのパスワードレスSSHアクセスが必要です。パスワードを使用してログインすることもできますが、GitoliteはSSHキーを使用しているため、キーを使用してログインするオプションを設定する必要があります。サーバーをパスワードレスSSHアクセス用に設定する方法がわからない場合は、まず設定方法を学んでください（SSHキー認証の設定に関するSteve OvensのAnsibleの記事がわかりやすく解説しています）。これは、サーバーのセキュリティを強化し、Gitoliteを効率的に運用する上で重要な部分です。

Gitユーザーを設定する

Gitolite がなければ、サーバー上でホストされている Git リポジトリへのアクセスを誰かが要求した場合、そのユーザーにユーザーアカウントを提供する必要があります。Git はgit-shellと呼ばれる特別なシェルを提供しています。これは Git タスクのみを実行するためのシェルです。これにより、非常に制限されたシェル環境からのみサーバーにアクセスできるユーザーをフィルタリングできます。

この解決策は一つのアプローチですが、グループ権限の適切なパターンを設定し、新しいリポジトリを作成する際にそれらの権限を厳密に遵守しない限り、ユーザーはサーバー上のすべてのリポジトリにアクセスできてしまうという状況が一般的です。また、このアプローチではシステムレベルでの大規模な手動設定が必要となり、通常は特定のレベルのシステム管理者のみが行う必要があり、Gitリポジトリの責任者が必ずしもその作業を行うとは限りません。

Gitoliteは、リポジトリへのアクセスが必要なすべてのユーザーにユーザー名を指定することで、この問題を完全に回避します。このユーザー名はデフォルトでgitに設定されており、Gitoliteのドキュメントではこのユーザー名の使用が前提となっているため、ツールの学習中はデフォルト設定のままにしておくのが適切です。これは、GitLab、GitHub、その他のGitホスティングサービスを使用したことがある人にとってはよく知られた慣例でもあります。

Gitoliteでは、このユーザーを管理対象ユーザーと呼びます。サーバー上に管理対象ユーザーとして機能するアカウントを作成します（慣例上、 gitを使用することをお勧めします）。

 $ sudo adduser -- create - home git

このgitユーザーアカウントを制御するには、アカウントにあなたに属する有効なSSH公開鍵が必要です。これは既に設定されているはずなので、公開鍵（秘密鍵ではありません）をコピーしてgitユーザーのホームディレクトリに追加してください。

 $ sudo cp ~ /.ssh/ id_ed25519 . pub / home / git /
 $ sudo chown git : git / home / git / id_ed25519 . pub

公開鍵の拡張子が.pubで終わっていない場合、Gitoliteはそれを使用しません。そのため、ファイル名を適切に変更してください。Gitoliteインストーラーを実行するには、該当するユーザーアカウントに切り替えてください。

 $ sudo su - git
 $ gitolite setup -- pubkey id_ed25519 . pub

インストールスクリプトを実行すると、 gitホームディレクトリにrepositoryディレクトリが作成されます。このディレクトリgitは（現在） git-admin.gitとtesting.gitというリポジトリが含まれています。これでこのサーバーに必要な設定は完了です。gitユーザーとしてログアウトしてください。

Gitoliteの使用

Gitoliteの管理には、Gitリポジトリ（具体的にはgitolite-admin.git ）内のテキストファイルの編集が必要です。Git管理のためにSSH経由でサーバーにアクセスすることはできません。GitoliteではSSH経由でのアクセスは推奨されていません。Gitoliteサーバー上に保存されたリポジトリはベアリポジトリであるため、使用を避けることをお勧めします。

 $ git clone git @example . com : gitolite - admin . git gitolite - admin . git
 $ cd gitolite - admin . git
 $ ls - 1
 conf
 keydir

このリポジトリのconfディレクトリには、 gitolite.confというファイルがあります。テキストエディタで開くか、 catを使って内容を確認してください。

 repo gitolite - admin
 RW +     = id_ed22519
 repo testing
 RW +     =   @all

この設定ファイルの機能については既にご存知かもしれません。gitolite gitolite-adminこのリポジトリを表し、 id_ed25519キーの所有者は Git の読み取り、書き込み、管理権限を持ちます。つまり、ユーザーを通常のローカル Unix ユーザーにマッピングするのではなく（すべてのユーザーはgitユーザーを使用してユーザー ID を管理するため）、 keydirディレクトリにリストされている SSH キーにマッピングします。

testing.gitリポジトリは、特別なグループ シンボルを使用して、サーバーにアクセスできるすべてのユーザーに完全な権限を付与します。

ユーザーを追加

aliceというユーザーを Git サーバーに追加するには、Alice から SSH 公開鍵を送信してもらわなければなりません。Gitolite はファイル名の.pub拡張子の左側にあるものを Git ユーザーの識別子として使用します。デフォルトの鍵名の値を使用する代わりに、鍵に所有者を示す名前を付けます。ユーザーが複数の鍵を持っている場合 (たとえば、ラップトップ用とデスクトップ用に 1 つ)、サブディレクトリを使用してファイル名の競合を回避できます。たとえば、Alice がラップトップで使用する鍵がデフォルトのid_rsa.pubである場合、これをalice.pubまたは同様の名前に変更し (または、ユーザーが自分のコンピューターのローカル ユーザー アカウントに基づいて鍵に名前を付けるようにし)、 gitolite-admin.git/keydir/work/laptop/ディレクトリに配置します。Alice がデスクトップ コンピューターから別の鍵を送信する場合は、その鍵にalice.pub (前のものと同じ) という名前を付け、 keydir/home/desktop/に追加します。別のキーはkeydir/home/desktop/などに配置される場合があります。Gitolite は、リポジトリの「ユーザー」に一致する.pubファイルをkeydir内で再帰的に検索し、一致するすべてのファイルを同じ ID を持つものとして扱います。

keydirディレクトリにキーを追加したら、サーバーにコミットする必要があります。これは忘れがちな作業ですが、Sparkleshareのような自動化されたGitアプリケーションを使うべき真の理由があります。Sparkleshareを使えば、変更内容はGitolite管理者に即座にコミットされます。最初のコミットとプッシュを忘れて、自分自身とユーザーのトラブルシューティングに3時間も無駄にしてしまった経験があれば、GitoliteこそがSparkleshareを使うべき完璧な理由だと分かるでしょう。

 $ git add keydir
 $ git commit - m 'added alice-laptop-0.pub'
 $ git push origin HEAD

デフォルトでは、Alice はtesting.gitディレクトリにアクセスできるため、これを使用して接続と機能をテストできます。

権限を設定する

ユーザーと同様に、ディレクトリ権限とグループは、おそらく使い慣れている（またはオンラインリソースで見つけられる）通常のUnixツールから抽象化されたものです。gitolite gitolite-admin.git/confディレクトリにあるgitolite.confファイルで、プロジェクトに権限を付与します。権限は4つのレベルに分かれています。

• Rは読み取り専用アクセスを許可します。リポジトリに対してR権限を持つユーザーは、リポジトリをクローンするだけで済みます。
• RWでは、ブランチの高速化、新しいブランチの作成、新しいタグの作成が可能です。ほとんどのユーザーにとって、RW は基本的に「通常の」Git リポジトリと変わりません。
• RW+ 、潜在的に破壊的なGitアクションを許可します。ユーザーは、通常のFast-Forwardプッシュ、ロールバックプッシュ、リベース、ブランチとタグの削除を実行できます。プロジェクトのすべてのコントリビューターにこの権限を付与するかどうかは、任意です。
• -リポジトリへのアクセスを明示的に拒否します。これは、リポジトリの設定にリストされていないユーザーの場合と同じです。

gitolite.confを調整することで、新しいリポジトリを作成したり、既存のリポジトリの権限を変更したりできます。例えば、Aliceにwidgets.gitという新しいリポジトリを管理する権限を付与するには、次のようにします。

 repo gitolite - admin
 RW +     = id_ed22519
 repo testing
 RW +     =   @all
 repo widgets
 RW +     = alice

これで、Alice (そして Alice のみ) がリポジトリをクローンできるようになります。

 [ alice ] $ git clone git @example . com : widgets . git
 Cloning into 'widgets' ...
 warning : You appear to have cloned an empty repository .

最初のプッシュでは、アリスは-uオプションを使用してブランチを空のリポジトリに送信する必要がありました (他の Git ホストで行うのと同じです)。

ユーザー管理を簡素化するために、リポジトリ グループを定義できます。

 @qtrepo = widgets
 @qtrepo = games
 repo gitolite - admin
 RW +     = id_ed22519
 repo testing
 RW +     =   @all
 repo @qtrepo
 RW +     = alice

グループリポジトリを作成できるのと同様に、ユーザーもグループ化できます。デフォルトでは、ユーザーグループ@allが存在します。当然のことながら、このグループには例外なくすべてのユーザーが含まれます。また、独自のグループを作成することもできます。

 @qtrepo = widgets
 @qtrepo = games
 @developers = alice bob
 repo gitolite - admin
 RW +     = id_ed22519
 repo testing
 RW +     =   @all
 repo @qtrepo
 RW +     =   @developers

キー ファイルの追加または変更と同様に、 gitolite.confファイルへの変更もコミットしてプッシュして有効にする必要があります。

リポジトリを作成する

Gitolite はデフォルトで、リポジトリの作成が上から下へ行われることを想定しています。例えば、Git サーバーへのアクセス権を持つプロジェクトマネージャーがプロジェクトリポジトリを作成し、Gitolite のリポジトリ管理システムを通じて開発者を追加します。

実際には、ユーザーにリポジトリ作成の権限を与える方が望ましいかもしれません。Gitolite ではこれを「…」と呼びます。ワイルド倉庫（無制限物流倉庫）ワイルドレポ(これがリポジトリの作成方法を説明しているのか、構成ファイルに必要なワイルドカードを指しているのかはわかりません。) 次に例を示します。

 @managers = alice bob
 repo foo / CREATOR /[ a - z ]..*
 C =   @managers
 RW + = CREATOR
 RW = WRITERS
 R = READERS

最初の行はユーザーグループを定義しています。このグループは@managersという名前で、ユーザーaliceとbobが含まれています。次の行では、ワイルドカードを設定することで、まだ存在しないリポジトリの作成を許可します。リポジトリは、リポジトリの作成に使用したユーザー名のサブディレクトリ、つまり ` fooというディレクトリ配下に作成されます。例えば、次のようになります。

 [ alice ] $ git clone git @example . com : foo / alice / cool - app . git
 Cloning into cool - app '...
 Initialized empty Git repository in /home/git/repositories/foo/alice/cool-app.git
 warning: You appear to have cloned an empty repository.

非公式リポジトリの作成者は、リポジトリへの読み取りと書き込み権限を定義するメカニズムを使用できますが、その範囲は限定的であることが多いです。多くの場合、Gitolite はプロジェクトの権限が特定のユーザーグループによって管理されることを前提としています。1つの解決策は、Git フックを使用してすべてのユーザーにgitolite-adminへのアクセスを許可し、変更をマスターブランチにマージするには管理者の承認を必要とすることです。

もっと詳しく知る

Gitolite は、この入門記事で紹介した以外にも多くの機能を備えていますので、ぜひお試しください。ドキュメントも充実しており、読み終えたら Gitolite サーバーをカスタマイズして、ユーザーに好みのレベルの制御を提供できます。Gitolite はメンテナンスの手間が少なく、インストールと設定さえ済めば、あとは放っておいても問題ないシンプルなシステムです。