バージョン管理システムを有効に使う

バージョン管理は、プロジェクトを構成するあらゆるものについて必要です。そのためには、Subversion 、Git、Mercurial、CVS などのフリーのバージョン管理ツール、大量のディスクスペース、安価でパワフルなサーバ、ユビキタスなネットワーク、さらにはプロジェクトホスティングサービスといったリソースを使うことになるでしょう。まずやるのはバージョン管理ツールのインストールです。インストールが終わったら、管理対象のコード以外に余分なものの置かれていない「クリーンな」ディレクトリに対し適切なコマンドを発行し、コードをリポジトリに登録します。バージョン管理ツールの操作は基本的には2種類しかありません。「コードの変更をリポジトリにコミットする」という操作と、「プロジェクトの作業ディレクトリで作業中のバージョンをリポジトリのバージョンと同期する(アップデー卜する)」という操作です。

プロジェクトのバージョン管理を開始すると、変更履歴が自動的に記録されます。誰がいつどんなコードを書いたのかが分かるようになり、ファイルやプロジェクトの特定のバージョンが問有のIDで取得できるようになります。重要なのは、こうしてバージョンを完全に符理しておけば、大胆なコード変更を恐れることなくできるということです。あとでわからなくならないように、コードを消さずにコメントアウトしておく必要もありません。古いバージョンは必ずリポジトリに残っているからです。ソフトウェアのリリースには個々にタグづけできます(そうすべきです)。リリース毎に、タグを見てすぐにそれとわかるような名前を作ることができるのです。タグづけをしておけば、いつでも好きなバージョンのファイルをすぐに取り出すことができます。プロジェクトのバージョンを、並行して進められているいくつかのブランチに分けて管理するということも可能です。多くの場合、プロジェクトはアクティプな開発ブランチと、すでにリリースされたバージョンをサポートするための保守ブランチ(複数の場合あり)に分かれています。

バージョン管理システムを使っていれば、担当者ごとに使うファイルのバージョンが違っている、というような事態の発生を防げます。個々のプログラマが自分の担当部分のことだけを与えて作業していても、バージョン管理システムが上手く同期をとってくれます。もし他人の担当部分に影響するような変更をした場合には、バージョン管理システムがその旨を通知し、矛盾の発生を防ぐのです。変更がコミットされる度にチーム全員に通知されるような設定もできます。そういう設定にしておけば、プロジェクト進行についての認識が人によって違う、ということは起きません。

プロジェクトを構成する要素は、とにかく何でもバージョン管理の対象にすべきでしょう。ソースコードだけでなく、ドキュメントやツール、ビルドスクリプト、テストケース、画像ファイル、ライブラリなど、ありとあらゆるものをバージョン管理の対象とするのです。プロジェクトのすべてをリポジトリに登録しておけば(そして、定期的にバックアップをとっておけば)、ディスクの破損やデータの消失によるダメージは最小限に食い止められます。開発マシンを新しくする際も、そのためのセットアップ作業は、リポジトリからプロジェクトをチェックアウトするというくらいで済みます。コードの配布、ビルドテストなどを何種類ものプラットフォームで行う場合も特に複雑な作業は必要ありません。マシン毎にアップデートコマンドを実行するだけで、ソフトウェアのバージョンが最新に保たれるからです。

バージョン管理システムはこのように非常に便利なものですが、有効に利用するためには、開発チームのメンバー全員が次のルールを守るべきでしょう。

• コードに意味のある変更を加える度に逐一コミットを行うこと。複数の意図の変更を一度にまとめてコミットしてしまうと、あとで個々の変更を別に扱うことが難しくなる。プロジェクト全体についてリファクタリングやスタイルの変更をする際には、このルールの道守がとても重要になる。複数の変更がまとまって扱われるということが起きやすいからである。
• コミットをする際には、必ずそのコミットについて説明するメッセージを添えること。少なくとも、どのような変更をしたのか簡単な説明を加えること。できれば、「なぜ変更したのか」という理由もメッセージに書いておくとよい。
• ビルドを壊すようなコードは絶対にコミットしないこと。そういうコードをコミットすれば、プロジェクトチームの全メンバーに恨まれることになるので十分注意するべきである。

どれも守るのが難しいルールではないはずです。こうしたルールを守るだけで、バージョン管理システムの有効性を保ち、プロジェクトを円滑に進めることができるのです。