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

» 2012年09月19日 00時00分 公開

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

まいん

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


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

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


$ git commit
亜琉美

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


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

と入力してコミットし、


$ git push
亜琉美

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


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

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


まいん

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


まいん

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


亜琉美

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


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

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

まいん

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


亜琉美

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


コミットメッセージ
アバター機能を追加(closes #14)
亜琉美

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


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

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


ぷりん

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


まいん

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


ぷりん

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


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

ぷりん

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


まいん

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


図8 ブランチによるチケットへの対応付け 図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 リポジトリブラウザ上でブランチを確認 図9 リポジトリブラウザ上でブランチを確認
亜琉美

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


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

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


まいん

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


ぷりん

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


Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。