マージ処理はコードを理解すべきである～チケット駆動開発の発展形

InfoQにマージツールの記事があったのでメモ。

【元ネタ】
関数を理解するマージツール

これは凄い。ソースコードを理解するマージツール「Semantic Merge」 | ソフトアンテナブログ

彼らの動機としては「優れたブランチは優れたマージから」という信念がある。
つまり、「タスクごとのブランチ」の考え方(トピックブランチ、フィーチャブランチなど)を強く支持しているが、結果的にブランチが乱発されてしまう弱点があり、もっと良いマージ機構が欲しかった、と。

だから、「マージ処理はコードを理解すべきである」という方針で、ツール自身がマージをサポートしてくれればいい、と。
Eclipseがリファクタリングをサポートしているように、ツールでもっと簡単にマージをサポートしたいのだろう。

彼らは、タスクごとにブランチ(Branch per Task)というブランチパターンを支持している。
つまり「イシュートラッカ(ITS)上のタスク単位で作業用のブランチを作る」アイデア。
イシュートラッカ(ITS)のエントリ(チケット)はひとつの変更、ひとつの新機能(バグ、機能、課題など)ごとに作られるから、それぞれにブランチが作られることになる。

この考え方は、ITSのチケット単位にタスクブランチ(トピックブランチ)を作ることと同義だ。
「チケット無しにフォークを許さない、マージを許さない」発想につながる。

この手法の利点は、真の並行作業になることから、trunkの品質を維持でき、新機能開発のためのコードフリーズがなくなるため、もっと素早いアジャイルな開発が実現可能になることだ。

ブランチとマージは表裏一体にある。
マージ機構がもっと強力になれば、ブランチがたくさんあっても構わない。

いつでも最新の機能、障害修正を取り込むことができる自信があれば、いろんな発想を実験したり、何度でもやり直しを行うこともできる。
つまり、真の意味での反復型開発をサポートするわけだ。

Gitが提供した強力なマージ機能とブランチ管理機能によって、XPが提唱したソースの共同所有というプラクティスを強力にサポートして、アジャイル開発の敷居をどんどん下げている。
開発インフラという技術がようやく時代に追いついてきたと実感している。