Gitoliteのリポジトリの基本的な使い方
クライアントから、Gitoliteのリポジトリへアクセスしてみましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
gitolite導入時に自動的に作成されるtestingリポジトリを無事クローンできました。失敗した場合は、環境変数「HOME」、「.ssh/config」ファイルの設定、秘密鍵が存在するかどうか確認してください。
適当に編集、コミットし、プッシュしてみましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
新しいユーザーの登録
初期状態では、管理ユーザーしか登録されていません。新しいユーザーを登録してみましょう。
鍵の作成(ユーザーの作成)
ユーザーの端末でssh-keygenを使って鍵を作成します。作成方法は、管理者用の鍵と同じですので、参考にしてください。ここでは、「okamototk.pub」(公開鍵)と「okamotototk」(秘密鍵)を作成したものとします。
また、ユーザーの端末上で「.ssh/config」の設定も忘れないようにしてください。ここでは下記のように設定してみます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
鍵が作成できたら、公開鍵を管理者に渡します。
公開鍵の登録
まずは、管理ユーザーでgitolite-adminリポジトリをクローンします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
gitolite-adminのディレクトリ構成は、下記のようになっています。
- gitolite-admin/
- conf/
- gitolite.conf(リポジトリの設定ファイル)
- keydir/(ユーザーの公開鍵を管理するディレクトリ)
- admin.pub(#gl-setup実行時に登録された管理者の公開鍵)
- conf/
上記のkeydirディレクトリに公開鍵をコピーすることにより、ユーザーを追加できます。keydirに公開鍵をコピーして、公開鍵のコミットとプッシュを行います。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
これでユーザーの登録は完了です。
次に、秘密鍵「okamototk」を登録したクライアント側で、以下のコマンドを実行すると、リポジトリがクローンできるはずです。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
新しいリポジトリの作成
さて、ユーザー管理が分ったところで、新しいリポジトリを作成してみましょう。リポジトリを作成するには、先ほどクローンしたgitolite-adminリポジトリの「gitolite.conf」を編集します。ファイルの中身は次のようになっており、gitolite-adminとtestingリポジトリが定義されているのが確認できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「atmark-repo」という名前のリポジトリを作ってみましょう。「gitolite.conf」に次の行を追加します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
後は、公開鍵の登録と同じ要領で、以下のように「gitolite.conf」をリポジトリへプッシュすれば、自動的にリポジトリが作成されます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
また、以下のコマンドでクローンできるようになります。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
リポジトリ一覧の表示
各ユーザーがアクセスできるリポジトリ一覧は、次のようにsshでリポジトリにアクセスすることで表示できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記の例では、「testing」というリポジトリに対して、読み書きの権限があることが分かります。
リポジトリのアクセス権の設定
リポジトリのアクセス権の設定を見てみましょう。リポジトリのアクセス権の設定では、リポジトリの作成で利用した、gitolite-adminリポジトリのgitolite.confを編集することにより行います。
アクセス権の追加
まず、アクセス権を変更してみましょう。先ほど作成したatmark-repoは全てのユーザーから読み書きできます。任意のユーザーに読み込みだけ許して、ユーザーokamototkのみ書き込みできるようにしてみましょう。gitolite.confのatmark-repoの設定を次のように書き換えます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
これで、全てのユーザー(@all)は読み取り可能(R)、okamototkんみ読み書き可能(RW)という設定になりました。編集した設定ファイルgitolite.confをコミットしてプッシュすれば設定内容が反映されます。
okamototk以外のユーザーでプッシュしようとすると、下記のようなエラーメッセージが表示され失敗します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
太字部分を見ると、adminユーザーにはatmark-repoへのアクセス権が許可されていないことを示しています。
グループの設定
1人づつアクセス権を設定するのは面倒です。gitoliteではグループを定義できます。例えば、次のようにグループの定義、利用を行います。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ここで、「RW+」というパーミッションが出てきました。Gitでは共有リポジトリ上のリビジョンを強制的に巻き戻す機能がありますが、「RW+」は、この機能を利用可能にするという意味です。
リポジトリが一般ユーザーにより巻き戻され、いきなりコミットがなかったことになるのは管理上好ましくないので、RW+はできるだけ使わないようにした方がよいでしょう。
ブランチのアクセス権
ブランチのアクセス権は次のように設定できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
この例では、dev-で始まるブランチは全てのユーザーが読み書きできますが、masterブランチは、okamototkしかアクセスできません。開発用のブランチとリリース用のブランチを分けて、リリース用のブランチはリリースマネージャしか書き込めないように設定できます。
ブランチ名には、正規表現が利用でき、「dev-」で始まるブランチではなく、「dev-」という名前のブランチのみにアクセス許可を与えたい場合は、以下のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
なお、あるブランチに対する読み取り権限を設定した場合、全てのブランチを閲覧可能になります。ブランチごとに制御できるアクセス権は、書き込み権のみなので、注意してください。
ファイルのアクセス権
次に、ファイルのアクセス権を設定してみます。先ほどブランチ名を記述していたところを「NAME/」で始まる名前に変更すると、ファイル・ディレクトリへのアクセス権の設定となります。
例えば、managerグループのユーザーにのみ、build.xmlの編集を許可し、developerグループのユーザーの書き込みは拒否する設定を行ってみます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
リポジトリ(もしくはブランチ)へアクセス権の設定が必要なので注意してください。パスへのアクセス権は、上から順に評価され、@developerグループのユーザーがbuild.xmlを書き込もうとすると、以下のルールに引っ掛かります。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「-」は、書き込み禁止のルールで、build.xmlはこのルールが評価され、書き込み禁止となります。build.xml以外のファイルは、上記のルールにはマッチせずに以下のルールにマッチし、書き込み可能となります。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
なお、この例で分かるようにNAME以下でディレクトリを指定した場合、そのディレクトリ配下のファイル全てにアクセス権を設定します。
設定のきめ細かさと手軽さを試してみよう
さて、Gitのリポジトリを管理するGitoliteについて紹介しました。Gitのリポジトリ管理には、UNIXアカウントを利用する方法や、HTTPプロトコルを利用する方法など、さまざまな方法がありますが、設定のきめ細かさと、ある程度の手軽さを考慮すると、Gitoliteが良い選択肢なのではないかと思います。Gitのリポジトリ管理に悩んでいる方は、ぜひGitoliteを使ってみてください。
オンラインで公開されているGitの書籍「Pro Git」の4章8節にもGitoliteの紹介が掲載されているので、そちらも合わせてご覧ください。
- exe/dmgしか知らない人のためのインストール/パッケージ管理/ビルドの基礎知識
- これでGitも怖くない! GUIでのバージョン管理が無料でできるSourceTreeの7つの特徴とは
- DevOps時代の開発者のためのOSSクラウド運用管理ツール5選まとめ
- GitHubはリアルRPG? そして、ソーシャルコーディングへ
- ついにメジャーバージョンUP! Eclipse 4.2の新機能7選
- いまアツいアジャイルプロジェクト管理ツール9選+Pivotal Tracker入門
- Git管理の神ツール「Gitolite」なら、ここまでできる!
- Java開発者が知らないと損するPaaSクラウド8選
- Eclipse 3.7 Indigo公開、e4、Orion、そしてクラウドへ
- AWSの自由自在なPaaS「Elastic Beanstalk」とは
- Ant使いでもMavenのライブラリ管理ができるIvyとは
- 「Hudson」改め「Jenkins」で始めるCI(継続的インテグレーション)入門
- Bazaarでござ〜る。猿でもできる分散バージョン管理“超”入門
- Review Boardならコードレビューを効率良くできる!
- Team Foundation ServerでJava開発は大丈夫か?
- コード探知機「Sonar」でプロジェクトの深海を探れ!
- 単体テストを“神速”化するQuick JUnitとMockito
- Java EE 6/Tomcat 7/Gitに対応したEclipse 3.6
- AzureのストレージをJavaで扱えるWindowsAzure4j
- 究極の問題解析ツール、逆コンパイラJD-Eclipseとは
- AWS ToolkitでTomcatクラスタをAmazon EC2上に楽々構築
- DB設計の神ツール「ERMaster」なら、ここまでできる
- Webのバグを燃やしまくるFirebugと、そのアドオン7選
- Googlerも使っているIntelliJ IDEAのOSS版を試す
- JUnit/FindBugs/PMDなどを総観できるQALab/Limy
- ブラウザを選ばずWebテストを自動化するSelenium
- Eclipse 3.5 Galileoの「実に面白い」新機能とは
- App Engine/AptanaなどJavaクラウド4つを徹底比較
- Aptanaなら開発環境とクラウドの連携が超お手軽!
- 分散バージョン管理Git/Mercurial/Bazaar徹底比較
- SubversionとTracでファイル管理の“迷宮”から脱出
- Trac Lightningで始めるチケット式開発「電撃」入門
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 分散バージョン管理Git/Mercurial/Bazaar徹底比較
ユカイ、ツーカイ、カイハツ環境!(3) - Bazaarでござ〜る。猿でもできる分散バージョン管理
ユカイ、ツーカイ、カイハツ環境!(20) - バージョン管理に便利なSubversiveプラグイン
CoolなEclipseプラグイン(15) - msysGitでWindowsからGitを使う
環境構築ステップ・バイ・ステップ - BitKeeperからgitへ、ソースコード管理ツール大変更
連載:Linux Kernel Watch 5月版 - Subversionによるバージョン管理
Apache 2.0でWebDAV(後編)