Git の add は CVS や SVN とは違う

「リポジトリに追加する」ため「だけ」に使用するものだとばっかり思ってた。
「WEB+DB PRESS Vol.50」の git 特集に出てくる「インデックス」と「ワークツリー」の説明がよく分からなかったのは cvs のノリで git を使ってて add の振る舞いを勘違いしてたからか。
git status でその動きを確認してみる。
まずは git リポジトリを作って、A と B のファイルを登録してコミットした状態にする。

repos
  |-- .git
  |-- A
  `-- B

A と B のファイルをそれぞれ編集して status を確認する。

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#	modified:   A
#	modified:   B
#

編集されてるけど update されていないファイルの一覧が表示される。ここで、ファイル A だけ add してみる。

$ git add A
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   A
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#	modified:   B
#

A は編集されているけどコミットされていないファイル、B は編集されているけど update されていないファイルとして表示される。コミットしてステータスを確認する。

$ git commit
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#	modified:   B
#

B が編集されているけど update されていないファイルとして表示される。add しないでいきなり commit してステータスを確認する。

$ git commit .
$ git status
# On branch master
nothing to commit (working directory clean)

ワーキングにコミットするものは何もないと表示される。

動きは分かったんだけど恩恵がよく分からないんだなぁ・・・。いつも「git commit .」で編集したファイルを一括でコミットしてたんだけど、一部のものをコミットしたい場合は「git add」してから「git commit」でいけるのが嬉しいんだろうか。それなら「git commit A B」の様にファイル名を指定したら同じだし(ファイル数が多いときついけど）。
「git add」でインデックスに登録(?)した状態であれば、編集を戻したり再編集したりできるのが嬉しい様に読み取れるんだけどなぁ(まだ全部読んでないけど)。add した状態じゃなくて commit しないと編集歴が残せないからいまいち利点が分からない。
「HEAD」「インデックス」「ワークツリー」がキーワードなんだろうけど読み取れないでいる・・・。