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

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

これまでのお話

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

　ひょんなきっかけから電子目安箱（カウンセラー）を開発することになった「ぷりん」と「まいん」の姉妹。第1回の『高校生になって初めてスクラムを始めました〜「ストーリー」で何を作るかまとめよう』、第2回の『スプリントと“かんばん”でチームのビートを刻め!! 〜スクラム開発で使う手法とツール〜』で取りあえず「スクラム」について勉強しました。

　連載第3回「スクラムやるならRedmineとALMinium！ 〜新キャラ登場！無表情なあの人が笑う日は来るのか？〜」では、ALMiniumを利用してRedmineのセットアップとプロジェクトを作成するところまで紹介しました。連載第4回「Redmineでスクラム実践！〜アジャイル開発始めました〜」では、いよいよRedmineを使ってスクラム開発を実践。一通り使ってみました。

■登場人物の紹介

【ぷりん】天然系の高校2年生

【まいん】ぷりんの妹。しっかりものの高校1年生

【亜琉美】まいんのクラスメート。無表情でナゾが多い

　前回の「『うわっ…私のバージョン管理、ダメ過ぎ…？』を解決するGitの使い方“超”入門」からは、「Git」について2回に分けて紹介しています。スクラムに必須ではありませんが、スクラムをはじめとしたアジャイル開発プロジェクトで最近広まりを見せています。バージョン管理システムの「Subversion」などを知らない人でも分かるように解説しているので、「Gitは難しい」という方も、前回と併せてぜひお読みください。

Git via kwout

チケットとコミットをつなぐ、3つのRedmine×Git連携機能

前回はGitの概要と使い方について話したけど、RedmineとGitを組み合わせると、Git単体で利用するのに比べて、いろいろと便利なことができるようになるんだよっ！ 今回は、RedmineとGitを組み合わせた利用方法を紹介していくよッ！

別に、おねーちゃんが紹介するわけじゃあないけどねー。まず、ALMiniumが提供するGitとの連携機能には、次の3つがあるよ。

• リポジトリブラウザ
  リポジトリのファイルの内容や変更履歴（コミット）、マージ履歴を確認できる
• コミット／ブランチとチケットの関連付け
  Gitのコミット／ブランチとチケットを関連付けることができる
• アカウント連携機能
  前回紹介した、Redmineのアカウントとアクセス権でGitのユーザーを設定する機能

3つ目のアカウント連携機能は前回紹介したから、今回は「リポジトリブラウザ」「コミット／ブランチとチケットの連携」について見ていくよ。

Gitなしでファイルや履歴が見えちゃうリポジトリブラウザ

リポジトリブラウザ機能を利用すると、コミットによる履歴を見ることができるよ。リポジトリやファイル、フォルダに「誰が」「いつ」「何のために」「どのような」変更を加えていったのかを確認できて、ファイルの内容そのものも見ることができるの。リポジトリブラウザのおかげで、GitクライアントをインストールしなくてもGitリポジトリの内容や変更履歴を確認できて、すごく便利ね。

亜琉美ちゃーん、使い方を教えてー。

承知しました。図1はリポジトリブラウザの画面ですが、リポジトリ内のファイルとコミットの履歴の表示がされているのが分かります。

図1　リポジトリブラウザ（左：コミット履歴の表示、右：コミットの差分の表示）

また、ブランチなどで枝分かれしたコミットもグラフで分かりやすく表示されています。図1の右はコミットのファイルの差分を表示した例です。赤の部分が削除された部分、緑の部分が追加された部分で分かりやすく表示されています。

ふ〜ん。これなら、開発経験がない私でもGitを使えるわねッ！次は、コミット／ブランチとチケットの関連付けについて見ていくよッ！

タスク捜査の名探偵「Redmine」

Redmineは、ストーリーやタスクを「チケット」と呼ばれる仕組みで管理しているんだよ。チケットは、プロジェクトの管理単位で、スクラムでは、ストーリー（プロダクトバックログ）やタスク（スプリントバックログ）などを管理するの。あと、バグ管理やシステムの運用などで利用する場合、インシデントなどもチケットで管理できるよ（図2）。

図2　チケットの概念

Redmine（ALMinium）では、その「チケット」をコミット／ブランチと対応付けることができます（図3）。

図3　コミット／ブランチとチケットの関連付け

例えば、図では次のように対応付けています。

• 【2】と【3】へのコミット：チケットID「24」の「投稿者が投稿を取り消す」というストーリーに対応
• 【4】へのコミット：チケットID「25」の「投稿に失敗する」というバグの修正に対応
• story/#23ブランチ：チケットID「23」の「生徒会は投稿に返信できる」ストーリーに対応

このように、コミットやブランチを対応付けると、ストーリーの実装は実際にどのようなコードが書かれたのか、バグの修正は具体的にどう修正したのか知ることができるよ。

この対応付けは、作業内容のレビューに利用したり、後で似たような実装やバグ修正を行う際の参考にするナレッジデータベースとしても利用できます。

ちょっと難しいけど、分かったかな？次ページでは、コミットとチケットの関連付けから見ていくよ。そのあとは、ブランチとチケットの関連付けだよッ！

コラム　これはリビジョンではないコミットである（by 茅場……（以下、自粛））

Gitやバージョン管理システムの説明では、図3のような図がよく示されますが、ここで簡単に説明しておきます。丸はリビジョンで矢印はコミットを表しています。

図3　コミット／ブランチとチケットの関連付け（再掲）

「コミット」は、git commitコマンドの実行で、ファイルへの変更のリポジトリへの反映を指します。リポジトリの変更内容と考えればよいでしょう。「リビジョン」は、操作としてのコミットにより変更されたリポジトリの状態を示します。

リビジョンは、コミットはGitでは「014d8535……」のようなハッシュ値で表され、リポジトリの状態を表すとともに、その状態へのコミットも同時に表します。

図3では、最初のファイルは【1】の状態で、ファイルを変更してコミットするごとに【2】【3】【4】……リポジトリのファイルの状態……、つまりリビジョンが進んでいることを表しています。また、【1'】【2'】【3'】は【1】から派生したブランチで、ブランチでもコミットごとに【1'】【2'】【3'】とリビジョンが進んでいきます。

【3'】から【5】へ線が伸びていますが、これは、【1'】〜【3'】までの変更をmasterブランチに【5】として取り込んだことを示しています。このブランチの変更の取り込みをマージと呼びます。【5】のようにブランチがマージされたときに発生するコミットを「マージコミット」と呼びます。

ちょっと紛らわしいですが、Gitのマニュアルや書籍にはリビジョンはコミット（commit）と記されています。「コミット」と書かれている場合、「操作としてのコミット」か「状態（リビジョン）としてのコミット」か考えながら理解する必要があるので、注意してください。