Gitのステージングエリアとは？addとcommitの間にある領域を図解で解説

ステージングエリアとは

ステージングエリア（Staging Area）は、Gitにおける「コミット前の準備領域」です。インデックス（Index）とも呼ばれます。git addでファイルを追加すると、変更内容はまずステージングエリアに登録され、git commitを実行したときにはじめてリポジトリに記録されます。

この仕組みにより、作業ディレクトリ内のすべての変更をコミットするのではなく、関連する変更だけを選んでコミットできます。たとえば、複数の機能を同時に修正した場合でも、機能ごとに分けてコミットすることが可能です。

3つの領域の関係

Gitでは、ファイルは「作業ディレクトリ」「ステージングエリア」「リポジトリ」の3つの領域を移動します。

領域	説明	状態
作業ディレクトリ	実際にファイルを編集する場所	変更が未追跡またはmodified
ステージングエリア	コミット対象として選択された変更	staged
リポジトリ	コミット済みの変更履歴	committed

この3層構造がGitの特徴であり、他のバージョン管理システム（SVNなど）との大きな違いです。

なぜステージングエリアが必要なのか

ステージングエリアがあることで、以下のような柔軟な操作が可能になります。

変更を選択的にコミットできる

1つのファイル内で複数の変更を行った場合でも、一部の変更だけをステージングしてコミットできます。

# ファイルの一部の変更だけをステージング
git add -p filename.js

-p（patch）オプションを使うと、変更を「ハンク」（変更のかたまり）単位で選択できます。「y」でステージング、「n」でスキップ、「s」でさらに細かく分割できます。

コミット前に内容を確認できる

ステージングした内容はgit diff --stagedで確認できます。これにより、コミット前に意図した変更だけが含まれているか確認できます。

# ステージングされた変更を確認
git diff --staged

# 作業ディレクトリの変更（未ステージング）を確認
git diff

論理的に意味のあるコミットを作れる

複数のファイルを修正した場合でも、関連する変更だけをまとめてコミットできます。これにより、コミット履歴が読みやすくなり、後からの追跡やrevertが容易になります。

ステージングエリアの基本操作

ファイルをステージングする

# 特定のファイルをステージング
git add filename.js

# 複数のファイルをステージング
git add file1.js file2.js

# すべての変更をステージング
git add .

# 特定のディレクトリ以下をステージング
git add src/

ステージングを取り消す

間違ってステージングした場合は、以下のコマンドで取り消せます。

# 特定ファイルのステージングを取り消す
git restore --staged filename.js

# すべてのステージングを取り消す
git restore --staged .

# Git 2.23以前の書き方
git reset HEAD filename.js

restore --stagedはステージングを取り消すだけで、作業ディレクトリの変更は保持されます。

状態を確認する

git status

出力例：

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   staged-file.js

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

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

表示	状態
Changes to be committed	ステージング済み（次のコミットに含まれる）
Changes not staged for commit	変更あり、未ステージング
Untracked files	新規ファイル、Gitで追跡されていない

ファイルの状態遷移

ファイルはGit内で以下の状態を遷移します。

状態	説明
Untracked	新規ファイル、まだGitで管理されていない
Staged	ステージングエリアに追加済み
Committed	リポジトリにコミット済み
Modified	コミット後に変更された

実践的な使い方

一部の変更だけをコミットする

git add -pを使うと、ファイル内の変更を部分的にステージングできます。

git add -p

対話的なプロンプトが表示されます：

@@ -1,3 +1,4 @@
 function hello() {
+  console.log("Debug");  // デバッグ用
   console.log("Hello");
 }
Stage this hunk [y,n,q,a,d,s,e,?]?

キー	動作
y	このハンクをステージング
n	このハンクをスキップ
s	このハンクをさらに分割
q	終了
?	ヘルプを表示

新規ファイルと変更ファイルを分けてコミット

新規ファイルの追加と既存ファイルの修正を別々のコミットにする場合：

# 新規ファイルだけをステージング
git add new-feature.js
git commit -m "feat: 新機能のファイルを追加"

# 変更ファイルをステージング
git add modified-file.js
git commit -m "fix: 既存機能のバグを修正"

変更を確認してからコミット

# 変更をステージング
git add .

# ステージング内容を確認
git diff --staged

# 問題なければコミット
git commit -m "変更内容の説明"

初心者が混乱しやすいポイント

git add . と git add -A の違い

コマンド	動作
git add .	カレントディレクトリ以下の変更・新規ファイルをステージング
git add -A	リポジトリ全体の変更・新規・削除をステージング
git add -u	追跡中ファイルの変更・削除のみステージング（新規ファイルは含まない）

Git 2.0以降、git add .は削除も含むようになりましたが、カレントディレクトリ以下に限定されます。リポジトリ全体を対象にしたい場合はgit add -Aを使います。

ステージングを取り消しても変更は消えない

git restore --stagedはステージングを取り消すだけで、作業ディレクトリの変更はそのまま残ります。

# ステージングを取り消す（変更は残る）
git restore --staged filename.js

# 作業ディレクトリの変更も取り消す（変更が消える）
git restore filename.js

注意：git restore（--stagedなし）を実行すると、作業ディレクトリの変更が失われます。取り消す前に本当に不要か確認してください。

コミットせずにステージングしたまま放置すると

ステージングしたまま別のブランチに切り替えると、ステージング内容も一緒に移動します。これは意図しない動作につながることがあります。

# ステージング状態を確認
git status

# ブランチを切り替える前にコミットするか、stashで退避
git stash
git checkout other-branch

ブランチを切り替える前に、作業中の変更をコミットするかstashで退避することをおすすめします。

ステージングエリアとインデックスは同じもの

Gitの公式ドキュメントやツールによって「ステージングエリア」「インデックス」「キャッシュ」と呼び方が異なりますが、すべて同じものを指しています。

呼び方	使われる場面
ステージングエリア	概念的な説明
インデックス	技術的な文脈、内部構造の説明
キャッシュ	古いドキュメント、一部のコマンドオプション

まとめ

ステージングエリアは、Gitの「コミット前の準備領域」です。

操作	コマンド
ステージング	git add ファイル名
ステージング取り消し	git restore --staged ファイル名
ステージング内容の確認	git diff --staged
状態確認	git status
部分的なステージング	git add -p

ステージングエリアがあることで、変更を選択的にコミットでき、論理的に意味のあるコミット履歴を作れます。git add -pを使えば、1つのファイル内の変更を分割してコミットすることも可能です。

コミットとは？の記事と合わせて読むと、Gitの基本的なワークフローがより深く理解できます。ステージングエリアを活用して、きれいなコミット履歴を維持しましょう。