一般的なweb系企業では、Gitを使う企業が多いです。
僕もチーム開発をする中で本格的にGitを触るようになりましたが、学習を進める中で以下のような疑問を持ちました。
git addって意味ある？
addなしでcommitできた方が楽だし早くない？
しかし、Gitの概念を理解していくと「git addはコミットログを綺麗にするためにも必須のコマンド」と認識するようになってきました。
今回は、学習の備忘録もかねて、
- git addの意味と必要性
- git addはどのように動いているのか
- git addの便利なオプション一覧
について解説していきます。
git addの意味は「コミットログを後から見返しやすくすること」
いきなり結論ですが、git addは「コミットログを綺麗にすること」という結論に落ち着きました。
なぜ、そのように考えたか？を理解するためには、Gitのステージングという概念について理解する必要があります。
詳しく解説していきます。
Gitにおける3つの作業エリア
Gitにはステージという概念があります。Gitの公式ページを引用してまとめると、Gitのローカルリポジトリにおける作業エリアは以下の3つになります。
- 作業ディレクトリ・・・現在編集を行っているファイルの集まり
- ステージングエリア・・・何をcommitするか選ばれたファイルの集まり
- Gitディレクトリ・・・commitされたファイルの集まり。remoteにpushすると反映される。
これを図解すると以下のようになります。
上記の図からわかりますが、リモートリポジトリに反映することができるのは、「add」「commit」の両方が完了された変更のみです。
つまり、git add（+ git commit）はリモートに反映したい変更を選ぶコマンドということができます。
git add でcommitしたい変更を選ぶことの意味
とはいえ、「今回行った修正は全て本番に反映する」なら、git add は不要なように思われます。
なぜなら、以下の図のように直接 git commit してpushして反映しても問題なく実現できるためです。
そこで必要になってくる考え方が、「コミットログを綺麗にする」という考え方です。
ここで話す綺麗なコミットログとは、1つのcommitに含まれる修正は1つだけの状態のことです。
しかし、実際の業務をしていると「このファイルを編集するなら、ついでにバグも直してしまおう」と修正を加えたくなりますよね。
仮にこの後に別のバグが発生しまうと、1つのcommitに2つの編集が加えられているのでcommitを戻す処理が難しくなります。
そこでgit addをすることによって、1つのコミットに必要な分だけコミットだけをすることで、コミットログを綺麗にすることができるのです。
git addが活躍する具体例
ここまでの説明だと、いまいちピンと来ない人もいると思います。そこで、より分かりやすいように具体例を紹介します。
先ほど紹介した、
実際の業務をしていると「このファイルを編集するなら、ついでにバグも直してしまおう」と修正を加えたくなる
という場合を考えてみます。ファイルAという1つのファイルに対して
- 機能の追加のためのコードを追記
- バグの修正のためにコードを編集
という2つの作業をやるとします。また、「1. 機能の追加」のためにはファイルBにもコードを追記する必要があるとします。
この場合、ファイルAにコードを追記した後にgit addし、ファイルBにもコードを追記してgit addすれば、「機能を追加する」という1つの変更に対して1つのcommitで済みます。
逆にgit addがなければ、1つの変更に対して2つのcommitがなされてしまい、コミットログが汚れます。
また、git addがあることで、ファイルAに加える変更を一気に行うことができます。
「1. 機能の追加のためのコードを追記」が終わった後にgit addしておけば、その直後に「2. バグの修正のためにコードを編集」を行ったとしてもステージングエリアにあるファイルAには影響を及ぼしません。
ファイルBに「機能の追加のためのコードを追記」した後にgit add→commitして、ファイルAの「2. バグの修正のためにコードを編集」に対してgit add→commitすれば、2つの変更に対して2つのcommitとなり、コミットログが綺麗に保たれるのです。
このように、git addがあることによって「何をcommitするのか」が選択しやすくなります。
コミットログがきれいであれば、サービスを運用するにあたって後から見直したときに「どこで」「どういう処理を」加えているのか明確になります。
そのためにaddコマンドがあるというわけなのです。
実際にgit addがコンソールでどう動くかを確認する
概念はなんとなくわかってきたものの、実際にコンソールを通してどのように見えるかも確認していくことにしましょう。
ステージングエリアのディレクトリ状況を確認する
ステージングエリアにおいて、作業ディレクトリと比較してどれほどファイルが反映されているか確認するためには、以下のコマンドを実行します。
% git status
上記のコマンドを打ち、緑色で表記されている index.html が自分の作業ディレクトリと同じ状態にあるファイルです。
赤い文字でmodified:と書かれているファイルは自分の作業ディレクトリのみで変更されている内容で、ステージングエリア以降には含まれていない修正になります。
Gitディレクトリの状況を確認する
Gitディレクトリの反映状況を確認するのは少し面倒な方法になります。Gitディレクトリの変更状況を調べるためには、
% git logで過去のcommitログを見ます。
その上で、自分が変更を見たいcommit idを見つけた上で
% git diff [commit id] [その直前のcommit id]を打つことで自分が以前のcommitから、どのファイルに変更を加えたかを見ることができます。
【おまけ】git add の便利なオプション一覧 [-A, -p, -u, -i, -f]
「git addの理解はコミットログを綺麗にすること」とお話しましたが、git addにはコミットログを綺麗にする様々なオプションがあります。
今回はその中でも、よくgit addに出てくる5つのオプションについて調べました。
git add -A
リポジトリ内に変更のあったファイル全てをステージングエリアに移動します。
特に補足などは不要かと思います。
git add -u
新規で作られたファイルを除いてリポジトリ内にあったファイル全てをステージングエリアに移動します。
git add -Aと混同されやすいですが、「新規で作られたファイルはaddされない」というのがポイントです。
git add -p
おそらく数あるgit addのオプションの中でも、最も実務で使うオプションかと思います。
git add -pでは、自分の意図した変更かどうか？を確認しながら、ステージングエリアに移動することができます。
試しにgit add -pコマンドを実行してみましょう。
% git add -p <file名>そうするとファイルの変更箇所に加え、以下の文言が出てくるでしょう。
Stage this hunk [y,n,q,a,d,/,s,e,?]?ここで、「y」と打ち実行すると対象箇所が add され、「n」と打ち実行すると対象箇所は add されません。
このようにしてそれぞれの変更箇所を addする/しないを決めることができるのです。
より詳しい解説は以下の記事にもあるので、合わせてご覧ください。
» git add -p 使ってますか？｜Qiita
git add -i
インタラクティブモードにして git add するファイルを変更することができるコマンドです。
正直、こちらは使えると便利かもしれませんが、あえて学習する必要もないので覚えなくていいかと思います。
git add -f
gitにはAWSのパスワード情報や外部ライブラリなどをステージングに上げないために .gitignore を設定することができます。
.gitignoreに書かれたファイルは基本的に git status などのコマンドでも表示されることはありません。
しかし、git add -fを使えばそれらのファイルも強制的にステージングエリアに移動できます。
とはいえ、秘匿情報をわざわざ git add することはないので、使い所のないコマンドといえます。
まとめ
今回はgit addの意味について調べてみました。
実務をやり始めるとgit addの重要性もわかりますし、綺麗なコミットログを残すことがいかに重要かも理解できます。
この記事を読んでGitの理解がさらに深まったようでしたら幸いです。
他にもGitのエイリアス設定のやり方についても紹介してます。Gitコマンドの入力が楽になります。合わせてご覧ください。
