PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み

PullRequestは分散バージョン管理の利点を生かしたコードレビューのパッチ取り込みなのだと下記の記事を読んでようやく分かった。
考えたことをラフなメモ書き。

【元ネタ】
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とご飯と甘いもの @ sotarok

Twitter / @obionekenobey: RT @akipii とても良い記事。Pull Requestの機能をRedmineで実現するのは可能なはず。「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とご飯と甘いもの @ sotarok

現在の開発では、trunk(マスター)に対して各開発者がブランチを作ったり、2次開発や大きめの機能の開発、別の顧客向けにカスタマイズする開発などでブランチを作るのはとても普通だ。
すると、マージ作業が発生し、そのマージ作業に非常に大きなコストがかかるのは従来から知られていた。

だが、GitHubが提供しているPullRequest機能を使えば、ブランチ作成(フォーク)→パッチ作成→PullRequest時にコードレビュー→OKならマージ完了という流れがスムーズに行える。
マスターからフォークすることで自分用のブランチを作り、そこで育てたパッチをマスター開発者へ送る時にPullRequest機能を使う。
そこで、自分が作ったパッチはマスター開発者の目にさらされるし、PullRequestによるパッチを誰が誰に送り、どんな議論があったのか、を他の人が参照することもできる。

僕がRedmineで並行開発を行なっていた時、その作業はチケットを経由してやり取りしていたが、コミット後にコードレビューしていたから良い運用とは言えなかった。
チケット単位のトピックブランチによる開発でも、そのトピックブランチはRedmineの管理下にないため、トピックブランチのパッチを手作業でチケットにアップしなくてはならない手間がかかる。

だが、RedmineのVer1.4以降では、SCMのマルチリポジトリ機能があるので、すべてのトピックブランチを登録して、PullRequestをチケット経由で行うようにするやり方もある。
そうすれば、チケットにコードレビューの結果が残るし、どんな経緯でそのパッチが作られて取り込まれたのか、という履歴が残るので、その後の運用保守で非常に役立つ。

できれば、RedmineでもPullRequestの機能を追加できるといいだろう。
実際の運用イメージとしては、マスターとなるリポジトリからブランチを派生できる機能、そのブランチのパッチをマスターへPullRequestする機能があればいいだろう。
つまり、ブランチがマスターのどのリビジョンから派生して、どのリビジョンへ取り込まれたのかが分かるような機能になれば良い。

GitやMercurialがコミット履歴の維持や改変の機能を強化しているように、コミット履歴や作業履歴はソフトウェア開発でとても重要なのだ。
仕様という結果だけではなく、その仕様が決まった経緯も知りたいのだ。

RedmineとGit又はMercurialを組み合わせたチケット駆動開発は、並行開発に関わるソフトウェア開発を大きく変える可能性があると思う。