変更を記録するgit addとgit commitの違いと使い方

これまでの記事で、GitのインストールからGitHubリポジトリの作成、そして他人のリポジトリを自分のPCにコピーする`git clone`までを学びました。あなたはもう、GitとGitHubを使った開発のスタートラインに立っています。

今回は、開発作業で最も頻繁に使う、変更を記録するための2つの重要コマンド`git add`と`git commit`に焦点を当てます。「どちらも変更を保存するコマンドじゃないの？」と思われがちですが、この2つは全く異なる役割を持っています。この違いを理解することが、Gitを使いこなす上で非常に重要な鍵となります。しっかりマスターしていきましょう！

Gitの基本概念：3つの「場所」を再確認

`git add`と`git commit`の違いを理解するために、まずはGitの基本ワークフローである「3つの場所」の考え方を復習しましょう。この概念が、2つのコマンドの役割を明確にしてくれます。

• 作業ディレクトリ (Working Directory): あなたが実際にファイルを編集しているPC上のフォルダです。
• ステージングエリア (Staging Area): コミット（記録）したい変更内容を一時的に置いておく「待合室」のような場所です。
• ローカルリポジトリ (Local Repository): ステージングエリアにある変更を、正式な履歴（コミット）として記録・保管する場所です。

この流れを「買い物」に例えると分かりやすいかもしれません。

1. 店の中を歩き回り、商品（ファイルの変更）を手に取る（作業ディレクトリでの作業）。
2. 買いたい商品をショッピングカートに入れる（git addでステージングエリアに追加）。
3. レジに行き、カートに入っている商品すべての代金を支払って購入を確定させる（git commitでロー-カルリポジトリに記録）。

このように、`git add`は「カートに入れる」という選択の操作、`git commit`は「購入を確定する」という記録の操作であり、役割が全く違うのです。

`git add`の役割：コミットする変更を「選ぶ」

`git add`コマンドの主な役割は、作業ディレクトリで行った変更の中から、次のコミットに含めたいものだけを選んでステージングエリアに送ることです。なぜこのような一手間が必要なのでしょうか？

それは、意味のある単位で変更履歴を残すためです。例えば、あなたが「ヘッダーの typo 修正」と「新しいフッター機能の実装」という2つの異なる作業を同時に行っていたとします。この2つの変更を1つのコミットにまとめてしまうと、後から履歴を見返したときに「このコミットは何をしたんだっけ？」と分かりにくくなってしまいます。

そこで`git add`の出番です。まずタイポを修正したファイルだけを`git add`してコミットし、その後にフッター機能のファイルたちを`git add`して別のコミットとして記録すれば、変更履歴が非常にクリーンで整理されたものになります。このように、`git add`はコミットの質を高めるための重要なステップなのです。

`git commit`の役割：変更を「記録」する

`git commit`コマンドの役割は、ステージングエリアに上がっているすべての変更を、一つの「セーブポイント」としてローカルリポジトリに永久保存することです。これがGitのバージョン管理の核となる操作です。

コミットには、必ず「コミットメッセージ」を添える必要があります。これは、そのセーブポイントで「何を変更したのか」を簡潔に説明するメモです。良いコミットメッセージを書くことは、未来の自分や他のチームメンバーが履歴を理解する上で非常に重要になります。

git commit -m "ヘッダーのナビゲーションリンクを修正"

このコマンドを実行した瞬間、ステージングエリアの内容がスナップショットとして撮影され、ユニークなIDと共にリポジトリに記録されます。一度コミットされた履歴は、意図的に操作しない限り、消えることはありません。

実践！addとcommitの具体的な使い方

では、`my-first-repo`フォルダを使って、実際のファイル操作で`git add`と`git commit`の挙動を確認してみましょう。

準備：2つのファイルを同時に変更する

まず、`index.html`と`style.css`の両方を編集して保存してください。

• `index.html`: `

  `タグを追加するなど、何か変更を加えます。

• `style.css`: `body`のスタイルを追加するなど、何か変更を加えます。

この状態で`git status`を実行すると、2つのファイルが変更されたと報告されます。

git status

ケース1: 1つのファイルだけをコミットする

「HTMLの変更だけを先にコミットしたい」というシナリオです。`git add`でコミットしたいファイルだけを指定します。

git add index.html

この時点で`git status`を見ると、`index.html`だけがステージングされ、`style.css`はまだ作業ディレクトリに残っていることが確認できます。

[画像：git statusの実行結果。index.htmlが緑色、style.cssが赤色で表示されている様子]

この状態でコミットを実行します。

git commit -m "HTMLの構造を更新"

これで、`index.html`の変更だけが記録されました。`git status`を再度実行すると、`style.css`の変更だけが残っているのが分かります。

ケース2: すべての変更をまとめてコミットする

次に、残りの`style.css`の変更と、新たに追加する`script.js`ファイルの変更をまとめてコミットしてみましょう。まず、新しいファイルを作成します。

echo "console.log('Hello, Git!');" > script.js

次に、`git add .` を使って、現在のディレクトリにあるすべての変更（`style.css`の修正と`script.js`の新規追加）を一度にステージングします。

git add .

最後に、これらの変更をまとめてコミットします。

git commit -m "CSSのスタイルを調整し、JSファイルを追加"

これで、すべての変更が記録され、作業ディレクトリはきれいな状態になりました。`git status`を実行すると "nothing to commit, working tree clean" と表示されるはずです。

コミットできたら、必要に応じてGitHubへpushする手順へ進みます。 逆に、間違ったファイルをaddしたり、コミット内容を戻したい場合は、次の取り消し記事を確認してください。

git status
git diff --name-only
git add templates/php/example-ja.php
git commit -m "Improve PHP article"