git add(ステージング)の使いどころ

Gitを使ってコミットする際には以下のコマンドを入力するでしょう。

git add .
git commit

これらはまとめて連続で実行することが多く、 git add コマンドでステージングすることの意味があまり分かっていませんでした。
Gitを使い始めのころはわざわざステージングの操作が必要な理由分かっていませんでしたし、実際に使うことはほとんどありませんでした。

最近になって git commit の前に実行する以外の使い方をするシーンがあることに気づいたので、その使い方をまとめました。

1. コミット対象のファイルを絞る

複数の機能を並行して実装したり、逆に実装中のコードを一部だけコミットしたい場合に利用できます。
もしステージングの機能がない場合を考えると、コミットしたくないコードの変更をいったん取り消す必要があるため、非常に手間でリスクのある操作になってしまいます。
もしくはGitがその仕様だった場合は git commit の引数で対象のファイルを指定するオプションがついていたかもしれませんが、ステージングと比べるとコミット前に確認しにくいので、ミスが発生しやすい操作になっていたでしょう。

実業務上では上記のようなシーンも出てきますが、ひとりで開発している分にはあまりなかったので、個人的には仕事で使わないとその有用性に気づけなかったことでした。
というかこれが本来の用途ですね。

2. テスト前にいったんステージングする

使い方

1. 実装が終わったらコードの確認をして、 git add . しておく
2. テストをしてバグを修正する
3. ワークスペースとステージングの差分だけコードの確認をする
4. git commit

意図

コミット前のコードの確認とテストは人によって順番が違うかもしれません。
自分も実装内容やその時の気分によって変わりますが、ちゃんとしてる時はコードの確認をして、実装に問題ないことを確認してからテストをします。

ですが、テスト中にバグが見つかった場合は追加でコーディングが必要となり、再度コードの確認を行うことになります。
その際にすでに確認済みのコードをステージングしておくことで、無駄に再確認せずに済みます。

とはいえ、ステージング後の修正がステージング済みのコードに影響がある場合はその限りではないですね。

3. テスト用の一時的なコードをコミットから排除する

使い方

1. 実装が終わったらコードの確認をして、 git add . しておく
2. テスト用の一時的なコードを追加すう（ログ出力の追加、判定文のコメントアウトなど）
3. テストが終わったら git commit

意図

2.と同様にテストに関連した使い方です。

テストをする際に動作を確認するためのログ出力を追加したり、状況を再現する手間を省くために判定文をコメントアウトすることがあります。（他の人もしてるのかな？）
テストの結果をより確実に確認できたり手間を減らしたりできるのですが、当然ながらコミットしてはいけないコードを記載している状態です。
これを明確に区別するためにステージングが活用できます。

ステージングなしで同じことをする場合、コミット前に不要なコードを消さないといけませんが、削除し忘れたり誤って必要なコードも削除してしまうリスクがあります。
こういった楽にテストをするための一時的なコードのリスクを減らすことができます。

終わりに

コミット前に git add .を実行すると無意味になるので手癖で実行しないように気をつけてください。
自分は何度もそのミスをしちゃっています。