プログラマの思索

Gitの使い方について良い記事があったのでメモ。

【元ネタ】
見えないチカラ: A successful Git branching model を翻訳しました

少人数開発に役立つ5つのまとめ

構成管理について良い本は、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」と「入門Git」の2冊。
これらの本を読んで理解した立場から書いてみる。

GitやMercurialのような分散バージョン管理では、ブランチをたくさん作るのが普通。
ブランチの目的を意識して、ブランチを管理するのが重要。

上記の記事では、メインブランチ、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチの4種類が紹介されている。
僕の理解では、記事に書かれているメインブランチはtrunk、フィーチャーブランチはトピックブランチ、リリースブランチはまさにリリースブランチ、ホットフィックスブランチはタスクブランチに相当すると思う。

メインブランチは、全てのブランチの本流。
継続的インテグレーションで常時ビルドされていて、安定して最新の機能が常時リリース可能なコードライン。
「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」ではメインラインモデルと呼ばれている。
この手法の利点は、trunkが全てのブランチの派生元なため、ブランチを新たに作ることが容易になること。

逆に駄目な構成管理は、trunkを次々に乗り換えていくパターン。
どのコードラインを参照してブランチを派生させればいいか、開発者が混乱してしまうから。

フィーチャーブランチは、特定の目的だけのためにハックしたり、バグ修正のパッチを当てたりするためのブランチ。
「入門Git」ではトピックブランチと呼ばれている。
トピックブランチでは、一つのトピックのためにブランチを派生させて、パッチを育てていく感覚。
トピックブランチへtrunkから最新のソースを取り込む時は、pullではなくrebaseが推奨されている。
rebaseなら、パッチを育ててきた履歴が残るから、後から修正理由を追跡しやすくなる。

上記の記事のリリースブランチは、リリース時期が決まりバージョン名が決まったら、派生させるブランチ。
メインライン(trunk)は最新の機能をどんどん拡張していくコードライン、リリースブランチは本番運用を前提としてバグ修正だけを行い、品質を重視するコードラインとして使い分ける。
つまり、機能拡張と本番運用の品質を重視する目的を分けたコードラインを保持することで、裏では機能拡張しながら安定した本番運用を行うことが可能になる。

ホットフィックスブランチは、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」ではタスクブランチと呼ばれている。
特定目的のためのブランチだが、トピックブランチとは違って、緊急性を持ったブランチの場合が多いだろう。
よくある例は、Ver1.0をリリース後、Ver2.0に向けて開発中のプロジェクトで、突然降ってきた顧客の要望を受入ざるを得ない場合、Ver1.1というバージョンを新たに作り、緊急リリースに対応する手法。
「成功する要求仕様 失敗する要求仕様」では、上記のような例に対する選択肢の中で、ベターな選択肢の一つがタスクブランチで緊急リリースする方法としてあげられていた。

CVS、SVN、GitやMercurialに至るバージョン管理の歴史をたどると、構成管理パターンを見出す歴史と重なる。
こういうノウハウがもっと広がれば、もっとプログラミングしやすくなるだろうと思う。