コード開発プロジェクトにおけるソース管理システムの正しい利用法：Beginner's Guide（4/4 ページ）

[Travis-Snoozy，Open Tech Press]

　そのほかによくやるミスとしては、個々のリリースとソース管理システムとの対応付けという、管理的な側面から発生するものがある。一般ユーザーの手元に配布可能な完成度に達したと判断された段階で特定のバージョンをつけた“リリース”を実施するというのは、どのようなソフトウェア開発プロジェクトでも行われている方式であろう。同様に開発リリースと安定リリースという使い分けも大部分のプロジェクトで用いられているが、これらはそれぞれ新機能を実装するための開発用バージョンと、そこにバグフィックスを施しただけのバージョンという意味で使用されている。もっとも、こうしたリリースの扱いに不慣れな人間にとって、リリース公開とは、単にソースリポジトリ上のコードがある程度完成したと判断した段階で行うtarボールの作成作業にすぎないのではなかろうか。しかしながらソース管理システムを利用すれば、よりシステマチックな方式でリリースを進めていけるはずで、実際そうすべきなのである。

　望ましい管理方式としては、個々のリリースごとにtarボールを無頓着に作成していくのではなく、ソース管理システム上にてタグ（tag）を用いたリリースの区分を行うべきである。ここでのタグとは、その名称からも推測できるように短めのテキストであり、このケースでは各自のリポジトリにおける時系列を区別するためのテキストをつけておく。具体的にはtarボールを作成してもよい完成度に達したら、該当するコードにリリース識別用のタグをつけてからtarボールを作成するようにしておけばいい。これにより特定のリリースを再現したり（誤って保管用のtarボールを削除してしまった場合など）、2つのリリース間に行われたチェックインを精密に管理できるようになる。

　タグ付けは実行する上での負担も小さく、CVSを利用する場合であっても、ローカルで行うチェックアウトと作成すべきリリースとが対応していれば次のようなコマンドで簡単にタグ付けが行える。

$ cvs tag release_1_0_0

　ソース管理システムを利用する上で、タグ付けそのものは特に難しい作業ではない。より困難なのは、安定リリースに施す変更をバグフィックスのみに限定しておくことである。そのためのアプローチは、ブランチを適切に使い分けることだ。まず安定版（例えば1.0など）として公開すべきリリースの準備が整えば、新規のブランチを設けると同時に当該ブランチへのタグ付けを直ちに行うようにする。その後行うメインラインへの機能追加時にも、安定ブランチについて施す変更はバグフィックスのみにとどめるようにしつつ、このブランチ上での適切なポイントにてタグ付け方式のリリース（1.0.1や1.0.2など）を継続していく。そしてメインライン側で開発していた新規機能を最終的に安定させるべき段階に到達したら、再び新たなブランチ（ここの流れでいうと1.1など）を設けた上で安定化のプロセスを再度進めていくようにする。こうしたアプローチを採用することで、ソフトウェアの開発過程で発生する雑多なバージョンを、各自のプロジェクトやビジネスモデルで課せられる要件に則した形でサポートできるはずだ。

原文へのリンク