the staging area
ステージングエリアこそが Git の本質たるコンセプトだ。ステージングエリアは作業のやり方を根本的に変えてしまう。もちろん、良い方向にだ。では、それがどういう仕組みなのか、使うにあたって何を知っておくべきなのかを復習しよう。
他の多くのバージョン管理システムでは、データを保管する場所は2箇所ある。ワーキングコピー（ファイルシステム上の今まさに触っているファイルとディレクトリ）と、バージョン管理システムがそれぞれのやり方で変更履歴を保存する場所、の2つだ。Git では、第三の選択肢がある。ステージングエリア（インデックス）だ。要するにこれは、どの変更を「送り出す」かを決めるための発送センターと言える。
ワーキングディレクトリと Git のコミット保管先はきちんと分離されているので、ステージングエリアのおかげで開発者は事前にコミットを組み上げることが出来る。いかに望もうとも、他 VCS がデフォルトでは備えていなかったテイストだ。Git がデータを保存するまでにレイヤーが一つ挟まることで、より柔軟なコントロールが可能になる。
ステージングエリアは git add と git commit だけで使える非常に簡単なものだ。つまりファイルをステージングエリアへ add して、変更の状態に満足したならばそれを commit する。
ひとたびリポジトリにコミットされたなら、それをリモートリポジトリへ push したり他のブランチへ merge したり、色々できる。ステージングエリア自身へ直接作用するコマンドも存在し、例えば 変更を stash する などだ。
ステージングエリアを使った簡単な例を見てみよう。以下は、いくつかファイルを変更したところだとする。
$ git status
On branch master
Changed but not updated:
(use "git add <file>..." to update what will be committed)
modified: README.md
modified: about.html
Untracked files:
(use "git add <file>..." to include in what will be committed)
help.txt
no changes added to commit (use "git add" and/or "git commit -a")
この例では Git が把握しているファイルを2ついじっており、1つのファイルがまだ登録されていない（help.txt）。 git add . を使えば、変更した全てのファイルと、まだ登録されていない全てのファイルをステージングエリアへ追加できる。 add コマンドはデータをまだ保存はしないが、次に git commit する時のための準備として発送センターにデータを置かせてくれる。
$ git add .
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README.md
modified: about.html
new file: help.txt
プロンプトが言うように git reset HEAD <file> でステージングエリアから変更を戻すことが出来る（なお、ファイル名とブランチ名が被っている場合は git reset <file> のように HEAD を省略してしまうとうまくいかない。HEAD を省略したい場合は git reset -- <file> とする）。このように、自分がしたいようにコミットする事が可能だ。 ファイル中の指定した行だけをコミットすることすら出来る。 ファイルの変更を捨てる方法が知りたいなら それ専用のまとめ TIPS 記事もある。
さてここまで来たら、 git commit を使うことで指定した全てのファイルを Git のデータ保管場所へ保存できる。以上だ。
$ git commit -m "Adding stuff" Created commit e793200: Adding stuff 2 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 help.txt
ステージングエリアに関する情報がもっと知りたいなら、以下の素晴らしい記事をチェックしてみよう。
ステージングエリアを解説した他の情報源を知っているなら、是非コメントで知らせて欲しい！
