git メモ
個人的に開発、運用している散歩DB（お散歩コースの記録管理をするWebアプリ）のソースコードを GitHub にあげてみた。
オープンソース開発始めちゃうぞとか、そういうのではなく、ライフログといっていい散歩のデータそのものも大事だけど、それを管理するためのアプリも必要不可欠で、ハードディスクがとんだりして失われないために（一応バックアップは定期的にとってはいるが）、オープンな場所においておこうと思ったのだ。
ソースコードのバージョン管理は git で行うことになる。今まで、小耳にはさむ程度でスルーしていたが、これを機会にちょっと勉強してみることにした。その内容を簡単にメモしておく。
git とは linux を開発した Linus Torvalds によって開発された分散バージョン管理システムだ。（名前の由来については Why the ‘git’ name?）今までデファクトスタンダード的に使われていた集中型のバージョン管理システム cvs や subversion とは、基本的な考え方が異なっている。
cvs や subversion では単一のレポジトリーとよばれる領域があって、ソースコードのメンテナンスを行う場合、そこからある時点（ほとんどの場合最新）のソースコードのスナップショットをダウンロードして、編集し、それをレポジトリーに書き戻すと、同時に編集履歴がレポジトリーに記録される。
git の場合はスナップショットをダウンロードするのではなく、レポジトリーそのものをローカルにコピーする。ファイルを編集すると、履歴はひとまずローカルのレポジトリーに記録される。つまり、バージョン管理だけなら、ローカル環境のみで行うことが可能で、競合は発生しない。編集した内容や履歴をレポジトリー間で同期をとるためのコマンドは別途用意されている。というあたりが、「分散バージョン管理システム」たるゆえんだ。
コピーされたそれぞれのレポジトリーは仕組み上対等だが、複数人で開発を行う場合は、マスターのレポジトリーを別に用意し、各人はそれと自分のレポジトリーの間で同期を行う形をとる。GitHub は git のマスターレポジトリーをホストしてくれるプロバイダーのひとつだ。
さて、とりあえず概念的な説明はこんなところにして、知っておくと便利な豆知識をいくつか。
- 既存の subversion（や cvs） の レポジトリーを履歴情報を含めて git のレポジトリーに変換することができる。（参照： Import from Subversion - Guides - GitHub）
- git では cvs 同様、空のディレクトリーをレポジトリーに含めることができない。含めたい場合は .gitigonore （git が無視するファイルを設定するファイル）を置くなどする。（参照： Can I add empty directories?）
- git には索引と呼ばれる、作業領域とレポジトリーの間にある中間的な領域が存在し、 「索引に変更を追加」、「索引をレポジトリーに反映」という2段階でコミットが行われる。
"git commit"コマンドは、索引をレポジトリーに反映するだけで、その前に"git add"コマンドで、変更したファイルを索引へ追加する必要がある。なお、"git commit -a"というように"-a"オプションを指定すれば、この2段階の処理を一挙に実行することができる。なお、"git commit -a"を使う場合でも新規にファイルをレポジトリーに追加するときは、事前に"git add"で追加しておく必要がある。（参照：Why is “git commit -a” not the default?） - 履歴から一括して特定のファイルを削除することが可能。つまり過去の歴史が修正できてしまう。（参照： Completely remove a file from all revisions - Guides - GitHub）