コグノスケ

休日出勤

休日出勤でした。日曜朝の電車は、乗客全員が座ってもなお席が空いていました。いつもこれくらい空いていて欲しいものだ…。

会社も空いていて静かでした。電話が一切かかってこないので捗りますね。

混乱してきた

会社でSubversionとGitを同時に使っているのですが、すごく混乱します。家ではさらにMercurialも使っているためさらに混乱します。

個々のシステムはどれもわかりやすいですし、良いと思いますが、3つ同時に使うと混乱してしまって、全く操作できません。いつかこの辺の違いをしっかりまとめたいけど、どうもやる気が出ないのですよ…。

ポリシー

かなりざっくりした説明ですが、各バージョン管理システムの動作概要です。ざっくりすぎとか、間違いに気づいたらぜひ教えてください。

Subversionの動作イメージ
管理外 <--(add/rm)--> ワーク <--(commit/update)--> リポジトリ

SubversionはCVSに似た体系、動作になっているようです（CVS使ったことないので知りませんけど）。CVS -> Subversion移行ユーザーの混乱を減らすためでしょうか。

Mercurialの動作イメージ
管理外 <--(add/rm)--> ワーク <--(commit/update)--> リポジトリ <--(push/pull)--> 他のリポジトリ

MercurialはSubversionの後釜を狙ったんだったか、コマンド名も動作もSubversionと似ています。しかし油断してると似て非なる部分でハマります。

Gitの動作イメージ
ワーク/管理外 <--(add/rm)--> ステージ <--(commit/reset)--> リポジトリ <--(push/fetch)--> 他のリポジトリ

Gitはステージという概念が他の2システムと異なります。ステージの存在を認識するまではcommitされる対象が理解できず混乱しますが、要らん変更をコミットしてしまうミスが減る利点もあります。

具体例

最も基本的と思われるコマンド群と、各システムでの挙動を以下に挙げます。

status/diff

リポジトリと作業領域の差分を見ます。
リポジトリ <--(status/diff)--> 作業領域

対象を省略した場合、Subversionはカレントディレクトリとその子ディレクトリを対象にしますが、Git, Mercurialは全リポジトリを対象にします。

commit/ci

作業領域の更新をリポジトリに反映させます。
作業領域 --(commit)--> リポジトリ

オプションを特に付けなかった場合、Subversion/Mercurialは変更されたファイル、追加(add)、削除(rm)したファイルをコミットします。Gitは変更(add)、追加(add)、削除(rm)によりステージに置いたファイルしかコミットしません。

またSubversionはカレントディレクトリとその子ディレクトリがコミット対象ですが、Mercurial/Gitは作業領域全体がコミット対象となります。

update

リポジトリの更新を作業領域に反映させます。
作業領域 <--(update)-- リポジトリ

対象を省略した場合、Subversionはカレントディレクトリとその子ディレクトリ、Mercurialはリポジトリ内の全ファイルが更新されます。Gitはresetコマンドが似ていますが、ステージにも影響を及ぼしてしまいます。

push

ローカルリポジトリの更新を別リポジトリへ送ります。
リポジトリ --(push)--> 他人のリポジトリ

MercurialもGitも同じような動きをします。Subversionにはありません。

pull

別リポジトリから更新を受け取って、ローカルリポジトリへ反映します。
リポジトリ <--(pull)-- 他人のリポジトリ

Mercurialはローカルリポジトリを更新するだけですが、Gitは作業領域も更新しようとします。Gitだとfetchが大体同じような動きをします。Subversionにはありません。