連載

2012年7月11日

「うわっ…私のバージョン管理、ダメ過ぎ…？」を解決するGitの使い方“超”入門：かんばん！～もし女子高生がRedmineでスクラム開発をしたら（5）（2/3 ページ）

本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。

[岡本隆史, イラスト：本橋ゆうこ，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 次のページへ

ALMiniumでGitを使うための準備

■共有リポジトリの準備

ALMiniumのプロジェクト作成時に、リポジトリ（［SCM］）で「Git」を選択すると、Gitのリポジトリが一緒に作れます。

図4　プロジェクト作成画面

ALMinium 1.xのバージョンでは、プロジェクト1つ対してリポジトリは1つしか作れなかったけど、7月にリリースされたALMinium 2.0からは、最新のRedmine 2.0を採用していて、1つのプロジェクトで複数のリポジトリを扱うマルチリポジトリが使えるようになったの。このマルチリポジトリ機能は、1つのプロジェクト（チーム）で複数のモジュールを開発するときに便利だよ。

それに合わせて、テーマもGitHub風になって前回までとちょっと画面の雰囲気が変わっています。以前のテーマに戻したい場合は、メニューの［管理］→［設定］→［表示］からテーマを変更してください。複数のリポジトリを使う場合は、リポジトリのパスを以下のように、ディレクトリ名の最後を｛プロジェクト名｝.｛識別子｝に設定してください。

/var/opt/alminium/git/counselor.test

このように名前を付けることで、Gitの認証にRedmineのcounselorプロジェクトのアクセス権限を利用できるようになります。

図5　リポジトリの複数管理

リポジトリを作成したら、プロジェクトのメンバーにユーザーを割り当てましょう。メンバーの割り当てを行って、初めてリポジトリに書き込みができるようになります。ユーザーの割り当て方は、連載第3回記事を参考にしてください。開発者もしくは管理者の「ロール」に割り当てると、リポジトリへの読み書きができます。閲覧者のロールに割り当てると、読み出しのみできます。報告者の場合、公開プロジェクトのみ読み出しができます。

**表1　ロールとリポジトリのアクセス権**
	リポジトリの読み込み	リポジトリの書き込み
管理者	○	○
開発者	○	○
報告者	△ (公開プロジェクトのみ)	×

■Gitの準備

リポジトリの作成が終わったら、次は、ユーザーのPC上での準備をしていくよ。Gitを利用する前に、使っているパソコンにGitをインストールして準備をしておいてね。Gitのインストールと設定は、記事『Git管理の神ツール「Gitolite」なら、ここまでできる！』のGitのセットップを参考にしておいてね！

Gitはシェルから利用するので、Windowsの場合、メニューからGit Bashを選択してGitが使えるシェル（bash）を起動します。LinuxやMac OS Xの場合、普通にターミナルを開いてシェルが使えるようにしてください。

図6 WindowsのGitの起動

Gitのセットアップが終わったら、最低限下記のようにユーザーの設定とhttpの設定をしておきます。

$ git config -global user.name ”紅まいん"             							名前
$ git config -global user.email mine@example.com         						 メールアドレス
$ git config --global core.editor "'C:/Program Files/sakura/sakura.exe' -code=4"  エディタを設定
$ git config -global http.sslverify false                     					   オレオレ証明書でのアクセスを許可

上記は「サクラエディタ」の設定例ですが、お好みのエディタを設定してください。コミットメッセージの編集などで利用されます。エディタの設定を省略すると、「vi」エディタが利用されます。最後の1行はALMiniumでは、認証機関に署名されていないSSL証明書を利用するので、SSLで利用する証明書による検証を無効にする必要があります。

リポジトリを苦労なくクローンする

さて、準備が終わったら、ALMinium上の共有リポジトリを取得してみましょう。適当なフォルダに移動して、「git clone」コマンドを実行します。例えば、ALMiniumをインストールしたサーバが192.168.1.1で作成したプロジェクトが「counselor」なら、下記コマンドのようにしてクローンを実行します。

$ git clone https://192.168.1.1/git/counselor

クローンを実行すると、リポジトリ名と同じ「counselor」というディレクトリができているので、そのディレクトリに移動してみましょう。

$ cd counselor
$ ls -a
.git/

「.git」という名前のフォルダがあるけど、.gitディレクトリの中にファイルの履歴情報がローカルリポジトリとしてコピーされているんだね。

counselarフォルダの中の.gitフォルダ以外のフォルダやファイルは「作業ツリー」と呼ばれていて、これから編集するファイルが置かれるんだよ。作りたてのプロジェクトでは、ファイルがないので、作業ツリーは空だけど、すでにファイルがコミットされていると、最新のファイルがコピーされるの。例えば、ALMiniumのリポジトリをクローンしてみると、下記のようにファイルやフォルダが確認できるんだよ。

$ ls -a
.git/         README.mkd   cache/   docs/  hooks/         theme/
.gitmodules   bin/         config/  etc/   inst-script/   smelt
uninstall

.gitを除くファイルやフォルダが「作業ツリー」なんだね。

次のステップで利用する適当なファイル（README.txtなど）を作業ツリー上に作成してみてください。.gitフォルダがあるファイルに作成します。ファイルを作成すると、下記のようになるはずです。

$ ls -a
.git/
README,txt

とあるGitのインデックス（とコミット）

ユーザーは、ファイルを編集して作業が一区切りが付いたら、ローカルリポジトリへ変更を反映するけど、この操作を「コミット」と呼ぶんだよ。コミットすると、変更内容はリポジトリへ記録されて、いつでも取り出せるようになるよ。

コミットするには、一度、「インデックス」と呼ばれる一時領域へ、変更個所（「hunk」とも呼ばれます）を登録する必要があります。

.「インデックス」って「とある魔術の……」

それ以上は、言わせねーよ、おねーちゃん。例えば、「A」というファイルを変更したけど、ファイルAの先頭の方は、あるバグを修正するために編集して、あるファイルの終わりの方は機能追加のために修正したとするよね。あと、バグ修正は、ほかに「B」というファイルも変更し、機能追加は「C」というファイルを追加したとすると、ちょうど図7のようになるんだけど……。

図7　バグ修正と機能追加の変更が混在した状況

こんなときは、変更の記録としてバグ修正に対するファイルの変更と、機能追加に対するファイルの変更を別々に登録（コミット）しておくと、ファイルの変更理由と変更点を対応付けられるんだよ。

ほかのバージョン管理システムでは、ファイル単位でしかコミット範囲を指定できずファイルAのバグ修正と機能追加を分けられないものあるけど、Gitなら、下記のように、インデックスを利用して2段階に分けることで、別々の変更点としてコミットできるんだよ。

1. バグ修正に関する変更をインデックスに登録
2. 1-1で登録した変更（hunk）をコミット
1. 機能追加に対する変更をインデックスに登録
2. 2-1で登録した変更（hunk）をコミット

図8　インデックスの登録とコミット

実際にファイルの変更をインデックスの登録は、下記のようにします。

 $ git add README.txt

インデックスに登録したファイルのコミット（ローカルリポジトリへの登録）は下記のようにします。

$ git commit
（※エディタが起動するので、「ドキュメント作成」と入力し保存して終了）
[master e2a59bc] ドキュメント作成
1 files changed, 2 insertions(+), 12 deletions(-)

コミットを実行すると、エディタ（標準ではvi）が起動するので、コミットメッセージ(ここでは「ドキュメント作成」)と入力するとコミットが完了してローカルリポジトリへファイルの変更が登録されます。コミット後に表示される下記は、「master」ブランチへコミットID「e2a59bc」としてコミットしたことを示しています。

[master e2a59bc] バグ修正

ちなみに、図8のように1つのファイルに異なる変更理由で変更された場所を別々に登録するには、下記コマンドを実行すると、各変更点をインデックスに登録するか選択できます。

$ git add -p

コミットメッセージには、変更内容ではなく、変更理由を書くようにした方がいいわよ。何でかっていうと、Gitを利用するとコミットした変更内容はコマンドで確認できるからなの。例えば、変更内容は、下記コマンドで変更履歴を表示して……。

$ git log

下記のように確認できるよ。

$ git show e2a59bc
commit c94b8c9c4b0470bdfd8732283c68024364cdea60
Author: 紅ぷりん <prin@example.com>
Date:   Thu Jun 21 23:20:43 2012 +0900
 
     ドキュメント作成
 
diff --git a/README.txt b/README.txt
index 0000000..740e191
--- /dev/null
+++ b/README.txt
@@ -0,0 +1 @@
+Gitのテスト

コミットメッセージの良い例と悪い例は、こんな感じだね。

悪い例「Authentication.javaを修正」←何を変更したかを説明
良い例「ユーザーがログインできないバグを修正」←何のために変更したかを説明

共有リポジトリへプッシュ！

ただし、この状態では、自分の編集内容をほかのユーザーが見られないんだよ。プッシュすると、ローカルリポジトリの内容は、共有リポジトリへ反映されて、ほかのユーザーからも参照できるようになるよ。

図9　プッシュ操作

プッシュはローカルリポジトリから、下記コマンドのようにします。

$ git push -u origin master

上記の「origin」は、「originという名前のリポジトリへローカルリポジトリのmasterブランチを送信する」ことを意味しています。共有リポジトリをクローンした場合、クローンしたリポジトリは自動的に「origin」という名前に、作業ブランチは「master」になります。

$ git push

作成したばかりのリポジトリには、ブランチがないので、リポジトリとブランチ名を指定する必要がありますが、2回目から（あるいは登録した後で別のユーザーが変更を送信する場合）は、下記コマンドだけで送信できるようになります。

こうして開発が進んでいき、共有リポジトリにどんどん変更が取り込まれると、今度は、自分のローカルリポジトリに共有リポジトリの変更内容を取り込む必要が出てくるの。次ページで説明するね。

プルとフェッチで、ほかの編集者の変更を取り込む