変更を記録する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): ステージングエリアにある変更を、正式な履歴(コミット)として記録・保管する場所です。
この流れを「買い物」に例えると分かりやすいかもしれません。
- 店の中を歩き回り、商品(ファイルの変更)を手に取る(作業ディレクトリでの作業)。
- 買いたい商品をショッピングカートに入れる(
git addでステージングエリアに追加)。 - レジに行き、カートに入っている商品すべての代金を支払って購入を確定させる(
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" と表示されるはずです。