チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法

@LightningXさんが、Redmine×Gitで新しい運用方法を提唱されていたのでメモ。

【元ネタ】
Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - ＠IT

Redmine×Gitのハーモニーは涙のチケット駆動開発!? (2/3) - ＠IT

Redmine×Gitのハーモニーは涙のチケット駆動開発!? (3/3) - ＠IT

Gitのような分散バージョン管理の場合、No Ticket, No Commitはどのように拡張されるのか？

(引用開始)
「チケット駆動開発」(Ticket-Driven Development、TiDD) と呼ばれるチケットベースで作業を管理する手法では、このコミットとチケットの関連付けが作業を管理するうえでのキーポイントになるんだよ。例えば、ストーリーの実装やバグの修正というチケットがあった場合、その作業でどこが変更されたのか、管理できるよ。
(中略)
ブランチのチケットへの対応付けは、図のようにブランチ名に「#」とチケットIDを入れてブランチを作成するだけです。例えば、チケットID「16」のチケットへ対応付けるブランチは「story/#16」のような名前で作ります。「impl-reply-func-#16」などのブランチ名にしても大丈夫です。

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

もしくは、

$ git checkout -b story/#16
(中略)
　図9と10を見ると、コミットメッセージの先頭に「refs #16」が付いていますが、これはRedmineのプラグインがコミットメッセージに自動的に関連キーワードを追加しているの。実際には、コミットメッセージには、「ブランチのコミットをチケットへの反映を実装」のようにチケット番号を含める必要はありません。
　これは、「story/#xx」というブランチ名を利用する例だけど、タスクに対応付けたい場合、「task/#xxx」、バグに対応付けたい場合「bug/#xxx」とすると、各ブランチが何の作業なのか分かって便利だよ。
(中略)
ポイントは、「git push」コマンドでプッシュが必要なところね。共有リポジトリにコミットを送信しないと、Redmine（ALMinium）側でコミットによりソースが変更されたことが分からないから、チケットと関連付けされるのは「プッシュした後」になるの。

$ git push -u origin story/#16
（初めてブランチをプッシュする場合）
$ git push
（2回目以降）
(中略)
「ブランチをマージしてからチケットを閉じる」と説明しましたが、「Redmine Git Branch Hook」（後述）というマージ時に自動的にチケットをクローズするプラグインがあります。例えば、先ほどコミットしていったstory/#16ブランチを次のようにしてmasterブランチへマージします。

$ git checkout master
（masterブランチへ移動）
$ git merge --no-ff story/#16
（masterブランチへstory/#16ブランチをmasterブランチへマージ）
$ git push
(引用終了)

上記の使い方を見ると、以下でまとめられる。

(1)チケット単位にブランチをoriginからフォークする
git branch story/#16

(2)フォークしたブランチ上の修正コミットは、Redmineのリポジトリブラウザへ自動でpost-commit-hookされる

(3)originへブランチからpushする
git push -u origin story/#16
または
git push

(4)ブランチの修正を一括マージして、チケットも同時にCloseする
git checkout master
git merge --no-ff story/#16
git push

僕が以前Subversionを使っていた時、Redmineの複数プロジェクト機能を使って、プロジェクトとブランチと同期させることによって、ブランチの変更履歴を管理しやすいようにしていた。
つまり、リリースブランチを作るたびにRedmineプロジェクトが作られて、次のリリースでプロジェクトもリリースブランチも廃止される運用を行なっていた。
しかし、この運用は、リリースするたびにプロジェクトが増えてしまい、逆に管理しづらくなる弱点があった。

Redmine1.4以降では、１プロジェクトで複数リポジトリを登録できるため、リリースブランチやトピックブランチ、フィーチャブランチなどは１プロジェクトにまとめた方がチケット管理しやすくなる。
上記のように、分散バージョン管理とITSを連携する場合、ブランチの生存期間をプロジェクトではなく、チケットの生存期間に合わせる方が運用しやすいだろう。

何故なら、GitやMercurialでは、複数のブランチが常に併存するのは当たり前であり、それらブランチの寿命は短いのが普通なので、ITSプロジェクトのように生存期間の長い機能よりもチケットの方が管理しやすくなるだろうと思う。
その利点は、トピックブランチのライフサイクルをチケットの生存期間と一致させることによって、ソース修正の変更履歴を記録しやすくできるからだ。

つまり、「チケット無しでフォークやプルリクエストは許さない」というチケット駆動の新しい運用方法と言えると思う。
「No Ticket, No Branch」という運用方法と呼ばれるかもしれない。

また、「この機能はGitHubで実装されている「プルリクエスト」と呼ばれる機能にインスパイアされたようです。開発者がブランチで開発を行い、ブランチの変更をレビューした人がマージする、という考え方の部分は、ほぼそのままですね。」という指摘も興味深い。
GitHubのプルリクエスト機能がとても素晴らしい理由の一つは、単なるマージ作業依頼だけでなく、パッチのコードレビューをオンライン上で実現できるようにしたからだと思う。
コミッタはプルリクエストを受け取る時点で、パッチの差分を必ずチェックする作業が自然に生まれるからだ。

GitやMercurialのフォークやプルリクエストは、単なるブランチ管理やマージ作業だけでなく、コードレビューという非同期ペアプログラミングを実現する重要な運用を生んでいることにも注意したい。