Git管理の神ツール「Gitolite」なら、ここまでできる！：ユカイ、ツーカイ、カイハツ環境！（26）（2/2 ページ）

» 2011年10月03日 00時00分公開

[岡本隆史，＠IT]

Gitoliteのリポジトリの基本的な使い方

　クライアントから、Gitoliteのリポジトリへアクセスしてみましょう。

> git clone ssh://gitserver/testing
Cloning into testing……
warning: You appear to have cloned an empty repository.

　gitolite導入時に自動的に作成されるtestingリポジトリを無事クローンできました。失敗した場合は、環境変数「HOME」、「.ssh/config」ファイルの設定、秘密鍵が存在するかどうか確認してください。

　適当に編集、コミットし、プッシュしてみましょう。

> git push origin master

新しいユーザーの登録

　初期状態では、管理ユーザーしか登録されていません。新しいユーザーを登録してみましょう。

鍵の作成（ユーザーの作成）

　ユーザーの端末でssh-keygenを使って鍵を作成します。作成方法は、管理者用の鍵と同じですので、参考にしてください。ここでは、「okamototk.pub」（公開鍵）と「okamotototk」（秘密鍵）を作成したものとします。

　また、ユーザーの端末上で「.ssh/config」の設定も忘れないようにしてください。ここでは下記のように設定してみます。

host gitserver-okamototk
    user gitolite
    hostname 192.168.1.8（Gitサーバのホスト名 or IP）
    port 22
    identityfile ~/.ssh/okamototk

.ssh/config

　鍵が作成できたら、公開鍵を管理者に渡します。

公開鍵の登録

　まずは、管理ユーザーでgitolite-adminリポジトリをクローンします。

> git clone ssh://gitserver/gitolite-admin

　gitolite-adminのディレクトリ構成は、下記のようになっています。

gitolite-admin/
- conf/
  - gitolite.conf（リポジトリの設定ファイル）
- keydir/（ユーザーの公開鍵を管理するディレクトリ）
  - admin.pub（#gl-setup実行時に登録された管理者の公開鍵）

　上記のkeydirディレクトリに公開鍵をコピーすることにより、ユーザーを追加できます。keydirに公開鍵をコピーして、公開鍵のコミットとプッシュを行います。

 > cd gitolite-admin/keydir
 > copy ｛公開鍵をコピーしたパス｝/okamototk.pub . 
 > git add okamototk.pub
 > git commit -m "岡本の公開鍵を追加。"
 > git push

　これでユーザーの登録は完了です。

　次に、秘密鍵「okamototk」を登録したクライアント側で、以下のコマンドを実行すると、リポジトリがクローンできるはずです。

 > git clone ssh://gitserver-okamototk/testing

新しいリポジトリの作成

　さて、ユーザー管理が分ったところで、新しいリポジトリを作成してみましょう。リポジトリを作成するには、先ほどクローンしたgitolite-adminリポジトリの「gitolite.conf」を編集します。ファイルの中身は次のようになっており、gitolite-adminとtestingリポジトリが定義されているのが確認できます。

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

　「atmark-repo」という名前のリポジトリを作ってみましょう。「gitolite.conf」に次の行を追加します。

        repo    atmark-repo
                RW     =   @all

　後は、公開鍵の登録と同じ要領で、以下のように「gitolite.conf」をリポジトリへプッシュすれば、自動的にリポジトリが作成されます。

 > git commit -a -m "atmark-repoを追加"
 > git push

　また、以下のコマンドでクローンできるようになります。

 > git clone ssh://gitserver/atmark-repo

リポジトリ一覧の表示

　各ユーザーがアクセスできるリポジトリ一覧は、次のようにsshでリポジトリにアクセスすることで表示できます。

# ssh okamototk
PTY allocation request failed on channel 0
the gitolite config gives you the following access:-2.el6
    @R_ @W_     testing
Connection to localhost closed.

　上記の例では、「testing」というリポジトリに対して、読み書きの権限があることが分かります。

リポジトリのアクセス権の設定

　リポジトリのアクセス権の設定を見てみましょう。リポジトリのアクセス権の設定では、リポジトリの作成で利用した、gitolite-adminリポジトリのgitolite.confを編集することにより行います。

アクセス権の追加

　まず、アクセス権を変更してみましょう。先ほど作成したatmark-repoは全てのユーザーから読み書きできます。任意のユーザーに読み込みだけ許して、ユーザーokamototkのみ書き込みできるようにしてみましょう。gitolite.confのatmark-repoの設定を次のように書き換えます。

        repo    atmark-repo
                R       =   @all
                RW      =   okamototk

　これで、全てのユーザー（@all）は読み取り可能（R）、okamototkんみ読み書き可能（RW）という設定になりました。編集した設定ファイルgitolite.confをコミットしてプッシュすれば設定内容が反映されます。

　okamototk以外のユーザーでプッシュしようとすると、下記のようなエラーメッセージが表示され失敗します。

# git commit -a -m "test." ;git push 
[master 1dac51d] アクセス権編集のテスト
 1 files changed, 1 insertions(+), 1 deletions(-)
W access for atmark-repo DENIED to admin
(Or there may be no repository at the given path. Did you spell it correctly?)
fatal: The remote end hung up unexpectedly

　太字部分を見ると、adminユーザーにはatmark-repoへのアクセス権が許可されていないことを示しています。

グループの設定

　1人づつアクセス権を設定するのは面倒です。gitoliteではグループを定義できます。例えば、次のようにグループの定義、利用を行います。

    @developer = okamoto okamura        .. 開発者
    @tester = sato szuki kimura         .. テスタ
    @admin = okamoto                    .. 管理者
    
……
    
    repo atmark-repo
        R   = @tester               .. テスタは読み込みのみ
        RW  = @developer            .. 開発者は読み書き可
        RW+ = @admin                .. 管理者はリポジトリの巻き戻し含め実行可能

　ここで、「RW+」というパーミッションが出てきました。Gitでは共有リポジトリ上のリビジョンを強制的に巻き戻す機能がありますが、「RW+」は、この機能を利用可能にするという意味です。

　リポジトリが一般ユーザーにより巻き戻され、いきなりコミットがなかったことになるのは管理上好ましくないので、RW+はできるだけ使わないようにした方がよいでしょう。

ブランチのアクセス権

　ブランチのアクセス権は次のように設定できます。

        repo    atmark-repo
                RW dev-  =   @all
                R  master =  @all
                RW master =  okamototk

　この例では、dev-で始まるブランチは全てのユーザーが読み書きできますが、masterブランチは、okamototkしかアクセスできません。開発用のブランチとリリース用のブランチを分けて、リリース用のブランチはリリースマネージャしか書き込めないように設定できます。

　ブランチ名には、正規表現が利用でき、「dev-」で始まるブランチではなく、「dev-」という名前のブランチのみにアクセス許可を与えたい場合は、以下のようにします。

                RW dev-$ = @all

　なお、あるブランチに対する読み取り権限を設定した場合、全てのブランチを閲覧可能になります。ブランチごとに制御できるアクセス権は、書き込み権のみなので、注意してください。

ファイルのアクセス権

　次に、ファイルのアクセス権を設定してみます。先ほどブランチ名を記述していたところを「NAME/」で始まる名前に変更すると、ファイル・ディレクトリへのアクセス権の設定となります。

　例えば、managerグループのユーザーにのみ、build.xmlの編集を許可し、developerグループのユーザーの書き込みは拒否する設定を行ってみます。

        repo    atmark-repo
        RW                 = @manager @developer
        RW  NAME/          = @manager
        -   NAME/build.xml = @developer
        RW  NAME/          = @developer

　リポジトリ（もしくはブランチ）へアクセス権の設定が必要なので注意してください。パスへのアクセス権は、上から順に評価され、@developerグループのユーザーがbuild.xmlを書き込もうとすると、以下のルールに引っ掛かります。

 - NAME/build.xml = @developer

　「-」は、書き込み禁止のルールで、build.xmlはこのルールが評価され、書き込み禁止となります。build.xml以外のファイルは、上記のルールにはマッチせずに以下のルールにマッチし、書き込み可能となります。

  RW  NAME/          = @developer

　なお、この例で分かるようにNAME以下でディレクトリを指定した場合、そのディレクトリ配下のファイル全てにアクセス権を設定します。

設定のきめ細かさと手軽さを試してみよう

　さて、Gitのリポジトリを管理するGitoliteについて紹介しました。Gitのリポジトリ管理には、UNIXアカウントを利用する方法や、HTTPプロトコルを利用する方法など、さまざまな方法がありますが、設定のきめ細かさと、ある程度の手軽さを考慮すると、Gitoliteが良い選択肢なのではないかと思います。Gitのリポジトリ管理に悩んでいる方は、ぜひGitoliteを使ってみてください。

　オンラインで公開されているGitの書籍「Pro Git」の4章8節にもGitoliteの紹介が掲載されているので、そちらも合わせてご覧ください。

「ユカイ、ツーカイ、カイハツ環境！」バックナンバー