コミットを適切に分けよう：git add . の危険性と代替策
はじめに
みなさんはgitの操作はCLIとGUIのどちらで行っていますか？
私はpushとpull cloneはCLI、それ以外はVSCodeで行っています。
使い方は人それぞれですが、仕事でgit addの使い方について気になったことがあったため、記事にしました。
この記事では、git add . の便利さとそのリスク、そして適切な使い方について解説します。
git add .とは
これは、gitを使っている人なら語るまでもないことですが、git addコマンドは指定したファイルをインデックスに登録するコマンドです。こうしてインデックスに登録されたファイルの変更は、git commitでローカルリポジトリに登録できます。
git add .は、現在のディレクトリ以下のファイルをすべてインデックスに登録します。
GitHubなどで新しいリポジトリを作成する場合によく使われるコマンドです。
git add .の悪い点
前述したように、git add .はすべての変更をひとまとめにインデックスに登録して、コミットできる便利で強力なコマンドになります。
一見すると何も問題のないコマンドに見えますが、このコマンドには大きな欠点があります。それは、現在のディレクトリのすべてのファイルが対象となることです。追加でいうなら、その対象となるファイルについての一切の確認がない点も問題です。
以下の例は、適当なリポジトリでのgit statusの結果になります。
$ git status
On branch develop
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: Dockerfile
modified: src/index.html
出力から見て、Dockerfile と src/index.htmlを変更しており、それがインデックスに登録されていないことがわかります。この場合、Dockerfileが環境関連の変更、src/index.htmlがフロントエンドの修正であることが考えられるため、それぞれの変更を分けてコミットすることが理想だと考えられます。
この状況でつい手を抜いてgit add .をしてしまうとすべての変更をインデックスに登録してしまうため、コミットを分けることができなくなってしまいます。
それが個人開発では問題になりにくいかもしれませんが、チームで開発している場合、1コミットに複数の変更がひとまとめにされるとそのコミットで何をしているのか分らなくなってしまい、結果としてチームの生産性を落としたり、バグの原因になったりします。
正直、gitの管理をしっかりしているところでそんなことをすれば普通に怒られると思います。多分。
解決策
じゃあどうすればいいのかについては、以下に示します。
方法1. git add <ファイル名>
普通に git add <ファイル名>で各ファイルを指定する方法です。
変更しているファイルの確認をしたい場合はgit status、変更差分は git diffを使いましょう。
# 変更しているファイルの確認など
git status
# 変更差分確認
git diff
# インデックスに登録
# ディレクトリを指定すれば、そのディレクトリのすべてのファイルを登録可能
git add src/index.html
git add src/js/
方法2. VSCodeを使用する
VSCodeにはGitの操作を行う機能があり、それを使うと簡単にコミットを分けることができます。
また、コミット対象のgit差分も簡単に確認できるため、個人的におすすめです。
方法3. Gitクライアントアプリを使用する
SourceTreeなどのGUIでGitを操作できるソフトを使う方法もあります。
こちらについて私は知見かないため、興味があれば調べてみてください。
おわりに
結論、「コミットを分ける癖をつけよう」！
Discussion