コマンドの数

Git はコマンドが多すぎてどれから手を付けて良いか分からない！って理由で Mercurial や他の DVCS に流れてしまう人はある程度いるんじゃないかと思います。
実際、そういうエントリをいくつか見たことがあります。
確かに、git help -a とすると、楽勝で 100 個を越えるコマンドが表示されます。確か 138 個だったと思います。
でも、git help と打ってみてください。最新版の 1.7.0.1 でも 21 個しか出てきません。Git を普通に使う分にはその程度のコマンドを理解していればいいのです。
このように、オプションを付けなければ Git 開発者がよく使うコマンドと判断した 21 個が分かるのです。とりあえずはこの 21 個からはじめればいい、という指針になります。

では、他のバージョン管理システムはどうなのか？というのが気になって調べてみました。

VCS	help で表示されるコマンド数
Git	21
Mercurial	87
Bazaar	14 だけど実質 12
Monotone	13 だけど実質 33
Darcs	33
Subversion	33
CVS	32

Bazaar が実質の個数が少ないのは、bzr help の説明が 3 つに分かれているからで、
Monotone が実質の個数が多いのは、コマンドの前にオプションについての説明も入っているからです。
コマンドの実質の個数を並び替えると、

Bazaar < Git < CVS < Darcs/Subversion < Monotone < Mercurial

となります。ヘルプという点では Bazaar が非常に優秀です。短くまとめられているだけでなく、グループ化も行われており、非常に分かりやすいです*1。
それに対して Mercurial は、すべてのコマンドを表示してしまっており、どれからはじめればいいのかここからは全然分かりません。
Mercurial ユーザからすると、「最初に見るのはそこじゃない！」という反論があるかもしれませんが、それだったら Git だって「コマンド数全体じゃなくて最初にこの 21 個のコマンドをやればいい！」となりますよね。

なので、Git がコマンド数が多いことを理由に避けられるというのは非常に悲しいものがあります。
これからはこの 21 と言う数字を押し出していけば、こういう事態が避けられるような気がします。

また、コマンドが多いことは問題になるかというと、むしろ便利なことの方が多いと感じています。
例えば、あるコミットでの変更のみを他のブランチにも適用したい場合に、Git では cherry-pick というコマンドが使用できます。

$ git cherry-pick bug/123

とするだけで、bug/123 での修正を現在のブランチに対して適用することができるのです。
これを例えば Subversion でやろうと思ったら、

$ svn merge -c 2137 file:///path/to/trunk

特定のリビジョンだけマージ(Cherry Picking)

このようになります。
さて、どちらが分かりやすいでしょうか？
Subversion との比較で言えば、ブランチの作成や切り替えでも同じようなことが言えます。
コマンドが多いことは、慣れてしまえばむしろ武器になりうるのです。

*1:ただし、pull や push と言った DVCS の特徴であるコマンドが一覧にありませんが・・・まぁ、Bazaar は DVCS としても集中管理型としても使えるので、こういう判断もアリだと思います