Redmine×Gitのハーモニーは涙のチケット駆動開発!?：かんばん！〜もし女子高生がRedmineでスクラム開発をしたら（6）（2/3 ページ）

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

[岡本隆史, イラスト：本橋ゆうこ，＠IT]

コミットとチケットの関連付け

コミットとチケットの関連付けのイメージとしては下の図みたいな感じね。

図4　チケットとコミットの関連付け

コミットはリポジトリに対する変更の単位で、1つの変更を1コミットと考えることができますが、リポジトリにコミットしたときに、チケットと関連付けができます。例えば、コミット時にコミットメッセージに

$ git commit

でコミットするときに、コミットメッセージとして、

コードレビュー機能を追加(refs #13)

と入力してコミットし、

$ git push

でプッシュすれば、チケットにリビジョン情報が表示され、リポジトリブラウザのリビジョン画面にrefs #13のキーワードで指定したチケット情報が表示されます。

図5　コミットとチケットの関連付け

リビジョンとチケットが関連付けられると、チケット番号やリビジョンをクリックすることにより、互いの情報を参照できるようになります。

ポイントは、「git push」コマンドでプッシュが必要なところね。共有リポジトリにコミットを送信しないと、Redmine（ALMinium）側でコミットによりソースが変更されたことが分からないから、チケットと関連付けされるのは「プッシュした後」になるの。

「チケット駆動開発」(Ticket-Driven Development、TiDD) と呼ばれるチケットベースで作業を管理する手法では、このコミットとチケットの関連付けが作業を管理するうえでのキーポイントになるんだよ。例えば、ストーリーの実装やバグの修正というチケットがあった場合、その作業でどこが変更されたのか、管理できるよ。

コミットメッセージに関連付けのキーワードを書き忘れた場合、リポジトリブラウザから選択したリビジョンからチケットへの関連付けができます（下図）。リポジトリブラウザからコミットを選択し、「関連するチケット」の【1】「追加」をクリックし、【2】チケット番号を入力し「追加」ボタンを押します。

図6　コミットからのチケットの関連付け

涙のチケット1人クローズ操作

お勧めはできない機能だけど、コミットしたときに作業が終了したことをRedmineへ伝え、チケットをクローズする（終了状態にする）こともできるの。

コミット時にチケットを終了状態にするには、コミットするときにコミットメッセージにclosesキーワードを利用して次のようにします。

コミットメッセージ

アバター機能を追加(closes #14)

すると、図7のようにチケットが自動的にクローズされます。

図7　コミットによるチケットのクローズ

ただ、この操作は他の人のレビューもなくチケットを閉じてしまうので、注意が必要ね。基本的には他の人による確認を挟んだ方がいいので、この機能は使わない方がいいよ。

変更して即チケットを閉じるっていうのは、テスト結果に自分で丸を全部付けて100点ってするようなものだね。なんだか寂しいよね（T_T）。それだと、本当に正しいかどうか分かんないしね……。

ちなみに、筆者はGitHubで、この機能をよく使っているみたいだよ。レビューしてくれる人がいないからコミットでチケット閉じても大丈夫なんだって。かわいそうに……（涙）。

「僕はレビューワーが少ない」「レビューは衰退しました」とかいいながら、クローズしているのかなぁ。ああ、なんか本当にやってそう……（涙）。

ブランチとチケット（ストーリー）の関連付け

さっき説明していたコミットとチケットの関連付けは、コミットに1つ1つチケットを指定する必要があるんだよね？でも、いちいち1つ1つにチケット番号を指定するのは面倒だよー。

ALMiniumには、ブランチにコミットすると自動的にチケットに関連付ける機能があって、ブランチ上で作業するだけで勝手にチケットに対応付けてくれるようになってるの。ストーリーの実装など、複数のコミットをまとめてチケットに関連付けたい場合、ブランチ上で作業するだけで自動的に関連付けされるから便利だよ。

図8　ブランチによるチケットへの対応付け

ブランチのチケットへの対応付けは、図のようにブランチ名に「#」とチケットIDを入れてブランチを作成するだけです。例えば、チケットID「16」のチケットへ対応付けるブランチは「story/#16」のような名前で作ります。「impl-reply-func-#16」などのブランチ名にしても大丈夫です。

具体的なブランチの作成とブランチへの移動は、

$ git branch story/#16
$ git checkout story/#16

もしくは、

$ git checkout -b story/#16

とし、ブランチを作成して作業します。ここで、いくつかコミットしていき、pushでコミットの内容を共有リポジトリへ反映させます。

$ git push -u origin story/#16
（初めてブランチをプッシュする場合）
$ git push 
（2回目以降）

リポジトリブラウザ上でstory/#16ブランチを指定して確認すると、ブランチにコミットされている様子が確認できます。

図9　リポジトリブラウザ上でブランチを確認

また、チケット#16を見ると、先ほどのコミットが対応付いているのが分かります（図10）。

図10　ブランチに関連付いたチケット

図9と10を見ると、コミットメッセージの先頭に「refs #16」が付いていますが、これはRedmineのプラグインがコミットメッセージに自動的に関連キーワードを追加しているの。実際には、コミットメッセージには、「ブランチのコミットをチケットへの反映を実装」のようにチケット番号を含める必要はありません。

これは、「story/#xx」というブランチ名を利用する例だけど、タスクに対応付けたい場合、「task/#xxx」、バグに対応付けたい場合「bug/#xxx」とすると、各ブランチが何の作業なのか分かって便利だよ。

次ページでは、「マージ」によるチケットのクローズ、ストーリー（プロダクトバックログ）とレビューについて説明するよ。レビュアーが少ない筆者が作ったプラグインも出てくるよッ！