git addの必要性がわからなかったのでstagingから調べ直した

会社に入りバージョン管理ツールとしてgitを使うようになりました。

学生時代にもgitは触っていたのですが、ファイルを編集してaddしてcommitしてpushするだけという作業を繰り返していたので、理解がかなり曖昧でした。

その曖昧な知識のまま業務をしていると、先日なんとremoteのmasterブランチにforce pushする失態をやらかしてしまいました。

ということで、今回は備忘録もかねてgitの基礎的な知識を学習したので備忘録として記述しておきます。

gitのステージについて

まず、gitには大きく3つのステージがあります。これがわかりにくいと思ったりもするのですが理解できると非常に便利なんですね笑

作業ディレクトリ・・・ローカルで編集しているディレクトリ。自分が編集したファイルの集まりと思えば良い。
ステージング・エリア・・・作業ディレクトリからaddされたファイルの集まり。commitするファイルを選択できる。
Gitディレクトリ・・・commitされたファイルの集まり。remoteにpushすると反映される。

の3つです。

一般的に私達がエディタで見ているのは作業ディレクトリと思ってもらえれば問題ありません。

つまり、自分が編集した作業ディレクトリが最新の状態であり、その最新の状態をステージング・エリアとGitディレクトリに反映させていかなければならないというわけなのです。

ステージング・エリアのディレクトリ状況を確認する

ステージング・エリアにおいて、作業ディレクトリと比較してどれほどファイルが反映されているか確認するためには、

$ git status

コマンドを使用します。


上記のコマンドを打ち、緑色で表記されている index.html が自分の作業ディレクトリと同じ状態にあるファイルです。


赤い文字で modified: と書かれているファイルは自分の作業ディレクトリのみで変更されている内容で、ステージング・エリア以降には関係ありません。

Gitディレクトリのディレクトリ状況を確認する

ステージング・エリアと比較して少々面倒なのがGitディレクトリの反映状況です。Gitディレクトリの変更状況を調べるためには、

$ git log

で過去のcommitログを見ます。

その上で、自分が変更を見たいcommit idを見つけた上で

$ git diff [commit id]

を打つことで自分が以前のcommitから、どのファイルに変更を加えたかを見ることができます。

git addの存在意義

変更したファイルをremoteにpushするだけなら、pushするファイルを選んでcommitすればいいんじゃない?

と思っていましたが、addはきちんと役割を持っていることがわかりました。

commit logの残し方

gitの大切な考え方として、1つのcommitに含める変更は1つだけという考え方があります。

例えばcommit例としては「ファイルを追加」「〇〇の機能を追加」などですね。このようにcommitを分けることにより、後からcommit logを見た時にどのような変更が加えられているかを一目で理解することができます。

しかし、実際の業務をしていると「このファイルを編集するなら、ついでにバグも直してしまおう」というときもあるでしょう。

仮にこのとき別のバグが発生しまうと、1つのcommitに2つの編集が加えられているのでcommitを戻す処理が難しくなります。

そこでgit addをすることによって、commitログをきれいに残す考え方が採用されているのです。

git addはcommitログをきれいにするための手段

git addは、このような状況を防ぐために「commitをする前にcommitをするべきファイルを選んでください」という処理なのです。

つまり、addを加えることによってcommitの粒度を明示的に決めることができます。

remoteに自分の編集を反映させるという意味では確かにaddは不要です。

しかし、commit logがきれいであればサービスを運用するにあたって後から見直したときに「どこで」「どういう処理を」加えているのか明確になります。

そのためにaddコマンドがあると思えばよいのではないでしょうか。

SNSでもご購読できます。

コメントを残す

*