分散バージョン管理の可能性

InfoQに分散バージョン管理の可能性の記事があったのでメモ。
ラフなメモ書き。

【元ネタ】
InfoQ: エンタープライズ分野での分散バージョン管理システム

(引用開始)
DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30分もかかっていた巨大なコードベースのブランチが２秒で済むようになり、マージも信頼できるようになった。
(引用終了)

(引用開始)
分散バージョン管理の本当の利点はブランチとマージを使って平行開発を推し進めることができる点にある。フィーチャーブランチ、タスクブランチ、リリースブランチというよく知られたブランチの切り方などを使えばとても優れた開発手法になる。この手法は前世代のSCMが適切なブランチやマージができなかったために忘れられていたものだ。
(引用終了)

【1】上記の解説の通り、GitやMercurialのような分散バージョン管理の利点は、ブランチとマージを自由自在に使った並行開発にある。
trunkをマスターのブランチとした場合、障害修正や機能追加など特定目的の開発は別ブランチで開発して、後でマージすればいい。
以前のCVSやSVNはマージ作業にとても神経質にやるしかなったが、GitやMercurialはマージコマンドが豊富で、コミット後の履歴すら後で改変することもできる。

Mercurialで独立並行リリース管理: プログラマの思索

Mercurialの黒魔術: プログラマの思索

Mercurialリポジトリの統合と分割: プログラマの思索

その場合、どのようなブランチ管理をすればいいのか？
拙著「Redmineによるタスクマネジメント実践技法」で紹介したのは、ソフトウェア構成管理パターンを参照したやり方。
「パターンによるソフトウェア構成管理」の内容は今となっては古くなっているが、構成管理パターンを明確に解説している本はこの本ぐらいしかない。

brainremix: ソフトウェア構成管理パターン

第3回 成果物や組織の管理方法「マネジメント・パターン」：ITpro

Redmineと構成管理パターンを組み合わせる場合、プロジェクトとブランチを対応付ける場合と、チケットとブランチを対応付ける場合の2種類がある。
後者はトピックブランチと相性がよい。
そのアイデアは以前書いた。

ReviewBoardとMercurial＋TiDDは相性が良い？: プログラマの思索

Mercurialによるチケット駆動開発は強力だ！: プログラマの思索

【2】ブランチ管理に関しては、「A successful Git branching model」というブランチ管理のモデルがGitで提唱されており、git-flow というコマンドを使えば実現できる。

git-flow による構成管理とRedmineの関係: プログラマの思索

A successful Git branching model: プログラマの思索

チケット駆動開発に分散バージョン管理を組み合わせるアイデア: プログラマの思索

また、この手法は、ブランチで作ったパッチをtrunkにPullすることでマージするため、GitHubのPullRequestに似た機能と密接に関係する。
以前はこのやり方が優れていると思っていた。

PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み: プログラマの思索

しかし、Redmine勉強会で丸山さんの発表資料を読んで、PullRequestという機能は実際の開発に向かないのではないか、と思っている。

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

Redmineの以前のコミッタEricと丸山さんのやり取りで、二人のマージに対する観点の違いが下記に記されている。

ChiliProject - Bug #127: Anonymous and Non member roles are not translated - ChiliProject

(引用開始)
Eric Davis が1年以上前に更新
Toshi MARUYAMA wrote:
Main line should use rebase. Revision graph is very dirty.

I disagree, see ChiliProject Repository for the details.
(引用終了)

ChiliProject - ChiliProject Repository - ChiliProject

1???Redmine 2.0 リリース ? shinagawa 20120519 v0.1 documentation

ChiliProjectは「A successful Git branching model」を採用しているが、複数人の開発者がパッチをtrunkへ直接Pullしているため、リビジョンを追いかけるのがとても煩雑。
PullやPushというマージコマンドは、コードラインにパッチをそのまま追加してしまうため、履歴があちこち分散してしまいがちになりやすい。

それに対して、Redmineのtrunkを見ると、trunkには唯一の開発用コードラインから必ずrebaseされる仕組みになっていて、リビジョンの履歴がとても分かりやすい。
また、rebaseする時に必ず定型的なコミットログが書かれているので、どのタイミングでrebaseされたのか、理解しやすい。

rebaseのイメージは、@yusuke_kokuboさんのつぶやきを参考にしたらとても分かりやすかった。
rebaseはメインラインへ別ブランチが合流するようなイメージのマージ作業のため、メインラインの履歴が改変されることなく維持される。

rebaseのイメージ: プログラマの思索

以前、まちゅさんから、PushやPullよりもrebaseを使った方がいいというアドバイスをもらった時があり、その意味を以前はきちんと理解できていなかったけれど、上記のやり取りを通じてrebaseの利点が何となく分かったような気がする。

【3】Redmineでは、Ver1.4からマルチリポジトリ機能が実現されたので、1プロジェクトで複数のリポジトリを追加できるようになった。
この機能によって、trunkから派生したトピックブランチ、リリースブランチ、タスクブランチなどは1個のプロジェクトにまとめることができる。
つまり、ブランチの寿命がとても短く、ブランチが派生された製品ではない場合、マルチリポジトリ機能を使うと、製品の機能改善や障害修正のブランチの履歴も同じプロジェクトのチケットから辿ることができる。

以前の僕は、Redmineの複数プロジェクト機能でブランチ管理するようにしていたが、この手法は派生したブランチが派生した製品に対応する場合だけで有効であり、トピックブランチのように寿命が短いブランチでは有効ではなかった。
子プロジェクトがたくさんできてしまい、逆に管理しにくくなったからだ。

Redmineプロジェクトとブランチ管理、ソフトウェア開発の組織構造の間には、密接な関係がある。
それは下記で書いた。

チケット駆動開発がもたらした新しい観点part1～Redmineプロジェクトへ案件や組織構造を反映する: プログラマの思索

チケットがRedmineプロジェクトに登録されたリポジトリに関するソース修正と関係するのだから、チケットの集合体であるRedmineプロジェクトは、リポジトリからビルドされるモジュールの変更管理を行なっていることになる。
Redmineプロジェクトはビルドモジュール、つまり製品と1対1に対応すると考えた場合、「アーキテクチャは組織構造に従う」というConwayの法則が自然に浮かび上がってくる。
つまり、製品のアーキテクチャや製品の変更に関するタスク管理の範囲は、Redmineプロジェクトと比例しており、その性質をうまく使えば、変更管理の見通しが良くなると思う。

分散バージョン管理は、この手法をもっと洗練化させてくれる可能性があるように思っている。