はじめに
こんにちは！新人エンジニアの @shinkaaaai です。
Gitは多くのソフトウェア開発の現場で使われており、研修などで学ぶ機会も多いと思いますが、Gitの真意が理解できずに、とりあえず使えるコマンドだけ覚えているという人も多いのではないでしょうか。(というか私がそうだった
)
特にgit addは初心者には中々理解が難しく、私もとりあえずgit add . とやっていた期間が結構ありましたが、先日社内の @k_uki512 主催のGitのLT会に参加した際にgit addのありがたさを実感したので共有したいと思います。
基本のおさらい
Gitはワーキングディレクトリとステージングエリアとローカルリポジトリという3つの状態を駆使して変更履歴を管理しています。
https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F より引用
ワーキングディレクトリは今の作業環境の状態のことです。今の作業状態の中から変更を記録したいファイルをgit add ファイル名とすると指定したファイルがステージングエリアに移ります。
そしてステージングエリアにあるファイルたちをgit commit -m "コミットメッセージ"とすることで、ローカルリポジトリにファイルが移動し、変更がコミットとして正式に記録されます。
ローカルリポジトリにあるコミットをGitHubなどで作ったリモートリポジトリに反映させるにはgit pushをします。リモートリポジトリに変更が反映されていることを確認したらpull requestを作り、他のエンジニアにレビューしてもらうというのが一般的な開発の流れになっています。
何も考えずにやりがちなgit add .
Gitはコミット単位で変更履歴を管理するツールです。綺麗にコミットを残すことで誰かにレビューをしてもらったり、元のバージョンに戻して実装し直すということがやりやすくなります。
ここまでの話を聞いていると、ワーキングディレクトリからローカルリポジトリに直接変更をコミットできた方が便利に思う人もいるかもしれません。確かにそれでも変更を記録するということはできます。
そうするととりあえずgit add . やgit add -Aなどで、全ての変更をステージングエリアに上げてコミットしてしまいがちです。
しかし、これはコミットをレビューする視点に立つと良くありません。具体例を使って説明していきます。
良くない具体例
あなたはSNSサービスの開発を行っています。今日は実装が進み、ユーザーネームの検索機能と投稿へのいいね機能の2つの機能を実装することができました！
そして、今日の変更分をまとめて次のようにコミットしました。
-
git add .で今日の変更分の全てをステージングエリアに上げる -
git commit -m "feat : 検索機能といいね機能の追加"としてコミットする -
git pushでリモートリポジトリに変更を反映させる
今日の変更分がリモートリポジトリに反映されていることを確認し、先輩エンジニアにpull requestを出したところ、先輩に少し嫌な顔をされました
どこが良くないのか
そもそもコミットはもっとこまめに行うべきです。
先ほどの具体例では、1つのコミットに"検索機能"と"いいね機能"という2つの追加機能の変更が反映されてしまっていて、レビューする側としては2つの機能のコードレビューを一気にやらないといけなくなるため、負荷が大きいです。この辺の話は@_miさんがまとめた素晴らしい記事が参考になるので是非読んでください。
どうすれば良かったのか
まず、検索機能といいね機能のコミットは分けたいのですが、その時にステージングエリアの有難さがわかります。
-
git add ファイル名で検索機能に関するファイルをステージングエリアに上げる -
git commit -m "feat : 検索機能の追加"としてコミットする -
git add ファイル名でいいね機能に関するファイルをステージングエリアに上げる -
git commit -m "feat : いいね機能の追加"としてコミットする -
git pushでリモートリポジトリに変更を反映させる
ステージングエリアがあることで2つの機能が実装されたのワーキングディレクトリの状態をそのままコミットするのではなく、機能ごとに実装したファイルを分けてコミットすることができています。
コミットを分けることで先輩エンジニアも機能ごとにコミットを確認すればよいので、コードレビューが各段にやりやすくなります
このようにgit add及びステージングエリアはコミットを整理するために存在しています。
git add . をどう使うのか
ここまでgit add . を使うのは良くない理由をひたすら書いてきましたが、このコマンド自体はとても便利で使いやすいものです。
大事なのはgit add . を何となく使うのはコミットが複雑になりがちなので辞めた方がいいということです。
git statusやgit diffで変更ファイルや変更部分を確認してから、この変更ならコミットに全部含めていいと考えて、git add . することは何の問題もありません。
まとめ
git addで使えるステージングエリアはコミットを整理するためにある- コミットに含める変更はできるだけ簡潔にしよう
git add .を使う前にgit statusやgit diffで変更箇所を確認しよう
私もこれからは綺麗なコミットを残せるようにgit addを使いこなしていきます！
もしこの記事が参考になると感じて下さったのなら、いいねやコメントを頂けるとこれからの励みになります