【Git入門】git add 確認を初心者向けにわかりやすく解説

Web開発•2025/2/21

はじめに

Gitでソースコードを管理するとき、git add は欠かせないコマンドです。しかし初めてGitを使う方の中には、「git add をした後に何が起きているのか」「どこまで変更されたかを確認するにはどうすればいいのか」と悩むことがあるのではないでしょうか。

これを理解していないと、誤って余計なファイルをコミットしてしまったり、逆に必要な変更をコミットし忘れたりすることもあります。本記事では、このgit add 確認にまつわる疑問を、初心者でもわかりやすい言葉で丁寧に解説していきます。

また、実務でどのようにgit addを活用すればいいのかも、ステージングエリアの概念やトラブル対策とあわせて紹介します。コード例も交えながらお伝えしますので、初めてGitを使う方でも安心して読み進めてみてください。

この記事を読むとわかること

git add で変更をステージングする基本的な手順
変更内容の確認方法（git status や git diff など）
ステージングエリアの仕組みと実務での活用シーン
git add にまつわるよくあるトラブルとその対処法

上記を理解することで、余計なコミットミスやコンフリクトの原因を減らすことが期待できます。それでは、始めていきましょう。

git add の役割とは

git add は、作業ディレクトリで行われた変更をコミットの対象にするため、ステージングエリアへ登録するコマンドです。 Gitには大きく分けて「作業ディレクトリ」「ステージングエリア」「リポジトリ」の3つの領域があります。

作業ディレクトリ: 実際に編集しているファイルがある領域
ステージングエリア: コミット対象として登録したファイルが一時的に置かれる領域
リポジトリ: コミットやブランチなどの履歴が記録される領域

Gitでは何か変更を行ったあと、いきなりコミットするのではなく、まず「ステージングエリア」に変更を登録してからコミットする流れになっています。この「変更をステージングエリアに登録する」作業が、git add の役割です。

一見すると手間に感じる方もいるかもしれませんが、この仕組みのおかげでコミットする内容を細かくコントロールできます。不要なファイルをコミットから外したり、一部の変更だけをコミットしたりできるので、後から履歴を見返すときに混乱せずに済むのです。

変更内容を確認する基本的な流れ

git add を実行する前後に、どのように変更内容を確認すればいいのかを把握しておくと、コミットの失敗や混乱を防ぎやすくなります。以下では、具体的なコマンド例とともに基本的な流れを見ていきましょう。

1. ファイルを変更する

まず、ソースコードなどのファイルを編集します。

2. 変更を確認する

変更内容は git status や git diff で確認します。

3. 必要に応じてステージングする

変更内容をコミット対象としたい場合、 git add <ファイル名> を実行します。

4. 最終確認をする

もう一度 git status や git diff --staged などで変更が正しくステージングされているかを確認します。

5. コミットする

問題がなければ git commit -m "コミットメッセージ" で変更を保存します。

それでは、これらのコマンドをもう少し掘り下げて紹介します。

git statusでの確認

ステージング前やステージング後の状態を簡単に把握できるのが、git status です。たとえば、以下のような出力結果が得られます。


$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
	modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	newfile.js

no changes added to commit (use "git add" and/or "git commit -a")

この例では、index.html が変更されていて、まだステージングされていない状態です。さらに newfile.js は新規に作成されたファイルで、まだGit管理下にありません。

git add index.html を実行し、もう一度 git status を実行すると、ステージングエリアに登録されていることが表示されます。


$ git add index.html
$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	newfile.js

このように、git status を使うことで、作業ディレクトリやステージングエリアの状況をひと目で確認できます。

git diff での変更確認

git diff は、テキストファイルの変更差分を表示するコマンドです。「何がどのように変わったのか」を把握するのに役立ちます。

通常の git diff

git diff だけを実行した場合は、作業ディレクトリとステージングエリアの差分が表示されます。ステージングされていない差分があるときは、それがどのように変更されたか確認可能です。


$ git diff
diff --git a/index.html b/index.html
index e69de29..9c1deef 100644
--- a/index.html
+++ b/index.html
@@ -0,0 +1,5 @@
+<html>
+<head>
+  <title>My Site</title>
+</head>
+</html>

git diff --staged

一方で、git diff --staged (もしくは git diff --cached) を使うと、ステージングエリアとリポジトリの差分が表示されます。つまり、すでに git add された変更内容 が表示されるわけです。


$ git diff --staged
diff --git a/index.html b/index.html
new file mode 100644
index 0000000..9c1deef
--- /dev/null
+++ b/index.html
@@ -0,0 +1,5 @@
+<html>
+<head>
+  <title>My Site</title>
+</head>
+</html>

これを使えば、「コミットしようとしている変更が何なのか」を最終的に確認できるため、コミットミスを防げます。 git add 確認 の要ともいえるコマンドなので、ぜひ覚えておきましょう。

ステージングエリアと実務での活用シーン

ステージングエリアは、単なる「一時置き場」というイメージを持ってしまうと、その便利さを活かせません。実務では、チームで開発するときに「コミットの粒度を小さくまとめる」「特定の問題修正だけをまとめてコミットする」といったケースが多々あります。

たとえば、複数のファイルを同時に編集していたが、そのうち1ファイルだけを先にコミットしたい状況があるかもしれません。このとき、git add で特定のファイルだけをステージングし、あとはステージングしないことでコミット単位を細かくコントロールできます。

コミット単位が大きすぎると、後から履歴を振り返るときに「どのコミットで何が変わったか」を理解しづらくなります。ステージングエリアを上手に使って、小さくまとまったコミットを積み重ねると履歴の管理が楽になります。

また、コミットごとに明確な目的を持たせることで、チーム全体がコードをレビューしやすくなるメリットもあります。実務レベルでは「Aというバグを修正したコミット」「Bという機能を追加したコミット」など、コミットの内容を一目で把握できるように意識すると良いでしょう。

git add のより細かい使い方

git add -p（パッチモード）

git add -p を使うと、変更したファイルを対話形式で部分的にステージングできます。例えば、1ファイルの中で数行だけコミットしたいというときは、このパッチモードが便利です。


$ git add -p
diff --git a/index.html b/index.html
index e69de29..9c1deef 100644
--- a/index.html
+++ b/index.html
@@ -0,0 +1,5 @@
+<html>
+<head>
+  <title>My Site</title>
+</head>
+</html>
Stage this hunk [y,n,q,a,d,e,?]?

ここで y と入力すると、その差分をステージングし、n と入力するとステージングしません。これを繰り返すことで、細かい単位でステージングする差分を選べます。

パッチモードは便利ですが、差分が大量にある場合は操作が煩雑になることもあります。状況に応じて、ファイル単位・行単位でのステージングを使い分けましょう。

git restore --staged

「ステージングしたはいいが、コミットから外したい」という場合は、git restore --staged <ファイル名> を使います。これはステージングエリアからファイルを取り除くコマンドです。以下の例では、 index.html をステージングから外しています。


$ git restore --staged index.html

もし、複数のファイルやディレクトリが対象なら、引数を続けて指定できます。このコマンドを覚えておくと、誤って不要なファイルまでステージングしてしまったときに助かります。

git add でよくあるトラブルと対処法

誤って余計なファイルをステージングしてしまった

ソースコードとは関係のない、テストログや画像ファイルなどをうっかりステージングしてしまうことがあります。手動で取り除くのが面倒だと思うかもしれませんが、先述した git restore --staged <ファイル名> で簡単に外せます。

一度コミットしてプッシュしてしまうと、取り消しや修正が厄介になる場合があります。そのため、コミット前に git status や git diff --staged などでしっかりと確認する習慣をつけましょう。

チームでのコンフリクトが発生した

複数人で同じファイルを同時に編集していると、コンフリクトが起こることがあります。これは git add の問題ではなく、Git全般の特徴ですが、事前に小まめなコミットやプッシュを行うことでリスクを下げられます。

コンフリクトが起きた際は、差分を比較しながらどちらの変更内容を反映させるかを決める必要があります。自分の変更が正しいからといって安易に上書きするのではなく、お互いが何を意図してそのコードを書いたか を理解したうえで解消しましょう。

大容量ファイルを間違えてステージングしてしまった

動画ファイルやデータファイルなどを誤ってステージングしてしまうと、リポジトリのサイズが大きくなりがちです。特にリモートリポジトリへプッシュすると、後から削除するのは手間がかかります。

最初に誤って git add しないように、.gitignore を設定しておくと便利です。たとえば、巨大なファイルや特定の拡張子をあらかじめGitの管理対象から外すことで、ミスを防ぎやすくなります。

まとめ

ここまで、git add を使った変更内容の確認方法や、ステージングエリアの仕組み、実務での活用シーンについて解説してきました。初心者が混乱しやすいポイントとして、ステージングエリアの存在はやや抽象的に感じられるかもしれませんが、そのおかげでコミットの自由度が高まり、きめ細かいバージョン管理ができるようになります。

git status や git diff で変更点をこまめにチェックしながら git add を活用することが、誤ったコミットを減らす大きなカギになります。また、git restore --staged やパッチモード（git add -p）を使うと、さらに細かい制御が可能です。

余計なファイルをステージングしてしまったり、コミット漏れを起こしたりするリスクを下げるためにも、ステージングエリアへの登録と確認をセットで行う癖をつけてみてください。そうすれば、チーム開発においてもスムーズにコード共有ができ、Gitの管理がより快適になるのではないでしょうか。

以上で、git add 確認 についての解説は終わりです。ぜひ日々の開発で活かしてみてください。