Redmine×Gitのハーモニーは涙のチケット駆動開発!?：かんばん！〜もし女子高生がRedmineでスクラム開発をしたら（6）（3/3 ページ）
「マージ」によるチケットのクローズ
ブランチで開発した場合、最終的にブランチのコミットはmasterブランチなどのメインの開発で利用しているブランチ（ここでは「masterブランチ」とします）へ反映するの。これを「マージ」と呼ぶんだよ。
マージによってブランチでの変更内容がmasterブランチなどへ反映されるよ。masterブランチへマージする前には、レビューやテストを行って問題ないことを確認してからマージするといいよ（図11）。
図11 ブランチのマージの概念図
masterブランチへマージすれば、ストーリーの実装などの1つの作業が終わったことになるので、チケットを終了にして閉じます。
チケットを終了にするときは、やっぱり「チケットは衰退しました」とかメッセージを入れるのかなぁ。「Ticket To Ride」 ならぬ「Ticket To Decline」で、まさに「涙の乗車券」だね……（T_T）。
「ブランチをマージしてからチケットを閉じる」と説明しましたが、「Redmine Git Branch Hook」（後述）というマージ時に自動的にチケットをクローズするプラグインがあります。例えば、先ほどコミットしていったstory/#16ブランチを次のようにしてmasterブランチへマージします。
$ git checkout master （masterブランチへ移動） $ git merge --no-ff story/#16 （masterブランチへstory/#16ブランチをmasterブランチへマージ） $ git push
マージした状態で、リポジトリの状態を確認すると、図12のようになります。
story/#16ブランチがmasterブランチへマージされているのがグラフで分かります。また、#16のチケットを見ると自動的にステータスが「終了」になっています。
ブランチの作成とチケットの関連付け機能をうまく使えば、以下のようにチケットをあまり意識することなくGitを使って開発作業を進めていけるよ。
- 作業の前にブランチ作成
- 作業→コミット、作業→コミット
- レビュー・テスト
- masterブランチへマージ
コミットを中心として開発するなら、「コミット駆動開発」って呼んでいい？
却下します。呼び名が増えると混乱します。
ひ、ひどいよ……。そんな冷たくいわなくたって……（T_T）。
ちなみに、ALMiniumのブランチとチケットの連携機能は筆者が開発している「Redmine Git Branch Hook」プラグインを利用しているみたいね。元のRedmineでもRedmine Git Branch Hookプラグインを利用すると、ブランチとチケットの関連付けできるようになるよ。
えっ？筆者ってプラグインなんて作れたの？こんな駄文しか書いてないのかと思ってた。これの開発もレビューしてくれる人がいないのかな……（涙）。
この機能はGitHubで実装されている「プルリクエスト」と呼ばれる機能にインスパイアされたようです。開発者がブランチで開発を行い、ブランチの変更をレビューした人がマージする、という考え方の部分は、ほぼそのままですね。
ストーリー（プロダクトバックログ）とレビュー
ところで、この連載ってスクラムの話だったと思うけど、レビューしてからチケットを閉じるという話が出てたけど、スクラムでコードをレビューするタイミングってどうすればいいの？
ストーリーごとにブランチを切って開発する場合、ストーリーに関するすべての作業（例えば、下の例では検討、実装、テスト）が終わったときが1つの目安になるかな。具体的には、“かんばん”が次のようにストーリーのタスクがすべて終了になったときね。
“かんばん”のステータスで「レビュー」があるので、「実装」のタスクがレビュー状態になったときにコードレビューを行を行ってマージする、というやり方もできます。
どれがいいかは人それぞれだと思うから、やりやすい方法でやるのがいいわね。流行としては、他の開発者に迷惑を掛けないように「テストしてからマージ」というのがいいみたいよ。
涙のチケット駆動開発の鍵ッ!?
今回はRedmineにおけるGitのコミットの使い方を見ていきました。コミット・ブランチとチケットをうまく使うことにより、何のために変更したのか、○○を実現するために、どこを変更したのか、ということが分かりやすくなります。
チケットとコミット・ブランチの対応付けは作業管理単位をチケットで行うチケット駆動開発にとってもキーとなる機能ね。Redmine Backlogsの“かんばん”でタスクを管理できるようになったら、ぜひコミットとの連携も試してみてね。
なんだか今日は、筆者のエピソードや亜琉美ちゃんの冷たいつっこみで涙を流してばっかりだった気がするな……（T_T）。でも、気を取り直して……。
今日の宿題を出すよー。私もやってみるから、みんなも一緒にがんばろーねッ！
■問1
適当なチケットを作成し、コミット時にメッセージに「(refs #チケット番号)」を含めコミットをチケットに関連付けてみましょう。チケットと関連付けるには、コミットを共有リポジトリへプッシュする必要があるので注意してください。
■問2
問1のrefsをclosesキーワードに変更し、チケットを閉じてみましょう。
■問3
別のチケットを作成し、「story/#チケットID」という名前のブランチを作成しブランチにコミット後、プッシュしてみましょう。チケット（ストーリー）を確認し、ブランチへのコミットが対応付いているかどうか確認してください。
■問4
問3のブランチをmasterブランチへマージし、チケットがクローズ状態になっていることを確認しましょう。
■本稿の図版について
本稿の図版は京風子（Kyoko）氏作成の「あんずもじ」フォントを利用しています。
関連記事
- Bazaarでござ〜る。猿でもできる分散バージョン管理
ユカイ、ツーカイ、カイハツ環境！（20） 「SubversionやCVSは使っているがGitなど分散型は難しい」という人にお勧めのBazaar。その特徴や使い方を徹底解説します - msysGitでWindowsからGitを使う
環境構築ステップ・バイ・ステップ 分散型のバージョン管理システム「Git」が注目されている。msysGitはGitをWindows環境で試してみるのに丁度いい - BitKeeperからgitへ、ソースコード管理ツール大変更
連載：Linux Kernel Watch 5月版 2002年以来使われていたBitKeeperに変わる、Linusお手製管理ツールが登場。 一方、いまだ議論が続くFUSEの現状は？
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。