Gitを使った分散開発管理1 – はじめるまえに

はじめに

その昔、とあるWebアプリケーションをServlet + JSPで開発していたころ、毎日作業終了時に開発ソースをまるごとコピーして所定の位置におき、ファイル名に日付をいれて履歴としてファイルサーバーに置いていました。

なにか問題がおこればそのバックアップから対象のソースコードを引っ張り出してきて比較したり、変更を何度も繰り返す際にはローカルディスクにおなじソースコードの少しだけ違うバージョンがたくさん存在していてどれが正しいものなのかわからなくなってたりしてました。

いま思えばなんと効率の悪いことをしているのだという感じですが、その時はバージョン管理システム（以下VCS)などという気の利いたものがあるなんて夢にも思いませんでした。そのWebアプリケーションの開発がおわってからほどなく、CVSというVCSを知りました。異なるバージョンのソースファイルをテキストで比較し、それを簡単にマージできたことに感動したのを覚えています。

それから月日が立ち、いくつものソフトウェア開発プロジェクトを経験しましたが、ほぼすべてのプロジェクトでVCSを使用していました。

このように、VCSはもっともよく使用されるソフトウェアの１つだと思います。VCSや分散開発についてよく知り、活かすことができれば、今後の開発がもっと無駄なく、楽に行うことができるようになるでしょう。

まずは従来の集中型バージョン管理とGit（ぎっと、と呼びます）などの分散バージョン管理について説明します。

集中型と分散型の違い

CVSやSubversionなどの昔からあるVCSは、集中型リポジトリといわれます。これは、中央にリポジトリが１つあり、このリポジトリへ対して各開発者がネットワーク越しに変更をやりとりします。

この集中型は、

• ローカルにあるソースは最新のものだけなので、履歴を参照するには中央リポジトリへのアクセスが必要
• ネットワークにアクセスできない場合、ソースの管理ができない

という問題点があります。

最近はノート型PCを持ち運び、さまざまな場所でコーディングをすることも多いと思います。そんなときにたまたまネットワークが繋がらない場所で作業したとき、リポジトリにアクセスできず、バージョン管理もできないとなると意味がまったくありません。この問題を解決するのが分散型リポジトリです。

分散型リポジトリは、変更を中央のリポジトリへ送るかわりに、ローカルに全体の履歴や自分専用のリポジトリを持ちます。コミットやソースファイルの比較などはネットワーク越しのリポジトリに接続する必要はなく、自分のローカルリポジトリに対して行います。もちろん、その変更を他のメンバーに同期させたり、他のメンバーの変更をもってくることも可能です。これをGitでは「push」「pull」といいます。

この分散型バージョン管理ツールはCVSやSubversionに比べると比較的新しいソフトウェアですが、プロジェクトの形態によっては、このようなローカルリポジトリを持つVCSが使用されるようになってきました。

次回は分散型バージョン管理ツールのGitについて解説を行います。