【Git】git add とは？使い方と実務での活用ポイントを初心者向けに解説

Web開発•2025/2/19

はじめに

皆さんはソフトウェア開発において、変更履歴を管理する必要性を感じたことはあるでしょうか。少しコードを変えたあとに、どのファイルをいじったか混乱してしまうケースも多いかもしれません。こういった場面で役立つのが Git というバージョン管理システムです。 Gitでは大きな変更から小さな修正まで、あらゆる作業を効率的に追跡できます。

その中でも git add は、いわゆる「変更をステージングエリアに登録する」ためのコマンドです。この一手間をかけることで、どのファイルをコミットに含めるかを制御できるため、誤ったファイルをコミットするリスクを減らすことができます。

しかし初心者にとっては、「コミットの前にgit addを実行するのはなぜ？」という疑問や、正しい使い方の流れがよくわからないといった壁にぶつかることもあるでしょう。そこで本記事では、git add の基本から実務での活用シーンまでを丁寧に解説していきます。

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

git add の基本的な役割と仕組み
よく使われるオプションの紹介と実務での活用方法
典型的なトラブルやエラーの対処法

なぜ git add が重要なのか

Gitを使い始めたばかりだと、「git commit を実行するだけで変更は登録できるのでは？」と感じるかもしれません。ですが、Gitには ステージングエリア と呼ばれる中間的な領域があります。 git add は、このステージングエリアへファイルを追加し、次のコミットでどのファイルを含めるのかをコントロールするために使われます。

たとえば何か新しい機能を実装しているとき、一部のファイルだけ先にコミットしたい場面が出てきますよね。すべてのファイルをコミットするのではなく、「変更のまとまり」がしっかり分割されていたほうが後から振り返りやすくなります。その区切りを手動で設定できることは、Gitが強力なバージョン管理システムとして評価される理由のひとつです。

ステージングエリアの役割

ステージングエリアがあることで、コミットしたい変更とコミットしたくない変更を明確に分けることができます。開発作業が大きくなればなるほど、一度の修正で複数のファイルを変更することも少なくありません。もし全ファイルを自動的にコミットしてしまうと、意図しないコードがコミットに混ざってしまうリスクが高まります。 git add を活用することで、こうしたリスクを下げて作業の粒度を調整できるわけです。

実務上のメリット

実務ではチームで開発するケースが多いでしょう。変更の意図を明確にするためにも、コミット単位をわかりやすく整理することが重要です。 git add でコミットの中身をしっかり選べば、レビュー時に「どのファイルがどんな目的で変更されたのか」を簡単に把握しやすくなります。無駄な差分をコミットに含めないようにすることで、他の人に影響を与えにくくなるのも大きな利点です。

git add の基本的な使い方

git add の使い方はとてもシンプルです。代表的なパターンをいくつか紹介します。

単一ファイルをステージに追加する


git add <ファイル名>

変更を加えた特定のファイルのみをステージに上げる場合、このようにファイルパスを指定します。例えば index.html に変更を加えたなら


git add index.html

と書くことで、次のコミットに index.html の差分が含まれるようになります。

複数ファイルをまとめてステージに追加する

複数のファイルを一度に追加したい場合、スペースで区切ってファイルを指定するか、ディレクトリ全体を指定します。


git add index.html style.css

あるいは


git add .

のようにドットを使うことで、現在のディレクトリ以下にあるすべての変更ファイルをまとめてステージに登録できます。

ただし、.gitignore によって無視リストに入っているファイルはステージに含まれません。やみくもに git add . をすると、意図しない変更もステージに加えてしまう可能性があるので注意が必要です。

変更部分だけをコミットしたい場合 (git add -p)

たとえば同じファイルの中で複数の修正を行ったが、その一部だけコミットしたいときがあります。そういうときは -p オプションが便利です。


git add -p

これを実行すると、ターミナル上で対話形式の画面が表示されます。 Gitが差分を自動的にブロック（hunk）ごとに分割してくれるので、「どのブロックをステージに入れるか」を質問形式で選べるようになります。もし一部分だけコミットしたいなら、その該当箇所だけをステージに取り込むといった使い方ができるわけです。

よくあるエラーと対処法

git add を実行するとき、ときどき想定外のエラーや挙動に戸惑うことがあります。初心者がつまずきやすいポイントとしては、以下のようなものが挙げられます。

fatal: pathspec 'ファイル名' did not match any files

タイポやディレクトリの構成ミスで、指定したファイルが見つからないときに出るエラーです。ファイル名が正しいか、相対パスやディレクトリ構造に誤りがないかを確認しましょう。

適切にステージングしたはずなのにコミットされない

実務で急いでいるときに陥りやすいのが、ファイルはステージングしたのにコミットメッセージを書き忘れたり、コミット自体をしていなかったりするケースです。コミットをする場合は、下記の流れを改めて意識するとよいでしょう。

ファイルを変更する
git add でステージに上げる
git commit でコミット
必要に応じてリモートリポジトリへ git push

意図せず大きなファイルもステージに入れてしまった

git add . を使うと、意図しないファイルをステージに含めてしまうかもしれません。その際は、 git restore --staged <ファイル名> を実行して、ステージングから除外しましょう。例えば、大容量の画像ファイルやビルド成果物（生成されたCSSやJSファイルなど）を誤ってステージに登録してしまったときは、すぐに除外しておくと安心です。

実務での活用シーン

現場でよくある作業の流れと、git add の活用方法を結びつけて考えてみましょう。

チーム開発での細かいコミット管理

同じプロジェクトに複数の開発者が関わる場合、コミットメッセージだけでは意図が分かりにくいことがあります。そこで、1つの機能を実装する際に複数のコミットに分割する人も多いでしょう。たとえば一部のCSSのみを調整したコミットや、JavaScriptだけを修正したコミットなど、単位を分けることでレビュー時にスムーズに差分が確認できます。

このようなときに役立つのが git add -p や、ファイル単位での git add <ファイル名> です。変更をキッチリ整理することで、「ここでCSSを修正」「ここでJSを実装」など、コミットメッセージを見たときに一目で内容を把握できます。

不要ファイルをあらかじめ除外する .gitignore の設定

新しくプロジェクトを始めるときには、.gitignore というファイルを用意することで、ステージに含めたくないファイルを事前に排除できます。よくある例としては、環境依存の設定ファイルや、ビルドで生成されるファイル、各種キャッシュデータなどを .gitignore に記述するやり方です。

# .gitignore の例
node_modules/
dist/
*.log
.env

このように書いておけば、 git add . をしても指定したファイルやディレクトリはステージに含まれません。ただし、一度でもステージやコミットに含めてしまったファイルは .gitignore だけで無視できなくなるので、先にファイルを除外したうえで管理するのが理想的です。

変更管理の粒度が大きすぎると、後から差分を追跡するときに「なんの作業をしたのか」わかりにくくなります。そのため、複数の作業が同時進行したときほど、こまめに add するファイルを選別すると良いでしょう。

git add をうまく活用するための流れ

初心者の皆さんでも実務ですぐに活かせるように、シンプルなワークフロー例をまとめます。

1. 変更ファイルを確認する

git status で変更されているファイルと、その状態をチェックします。

2. ステージに追加するファイルを選ぶ

必要に応じて git add <ファイル名> や git add -p で変更部分を限定します。一度に多くのファイルをステージする場合は git add . を使うケースもありますが、不要なものを含めないよう注意してください。

3. コミットを実行する

git commit -m "コミットメッセージ" の形式でコミットを行います。メッセージは短くて明確な表現にしておくと読み返しやすいです。

4. リモートリポジトリへ反映する（必要に応じて）

共同開発をしている場合は、 git push <リモート名> <ブランチ名> を実行し、変更を共有します。

この流れを習慣化すれば、作業内容をわかりやすく整理でき、チーム内のコミュニケーションもスムーズになります。

実行時に --force を多用するのは避けたほうが良いです。間違ったステージングやコミットを修正するために、むやみに履歴を上書きしてしまうと、他のメンバーにも影響を及ぼす可能性があります。

まとめ

ここまで git add の基本的な使い方や役割、そして実務でどのように活用するかについて解説してきました。コミット前にステージングを行うことで、変更内容を細かく選別できるのが大きなメリットです。特にチーム開発では、差分をわかりやすく管理するために、ステージングエリアをしっかり使いこなすことが重要になるでしょう。

初心者の皆さんにとって最初は少し面倒に感じるかもしれませんが、コミットを適切に分割する ためにはステージングエリアが必要不可欠です。ぜひ実務の流れに組み込んで、整理されたバージョン管理を実現してみてください。