Git statusを読む：変更・ステージング・未追跡ファイルを区別する

ファイル修正からコミット準備まで

手順1	現在のファイルを修正・保存
手順2	statusで状態を確認
手順3	diffで未準備の変更を確認
手順4	必要なファイルをステージ
手順5	cached diffで準備内容を確認

読む順序を整理した説明図です。実際のプログラム画面や測定結果ではありません。

Gitを初めて使うと、保存したのに「コミットする変更なし」と出たり、修正したファイルが二つの一覧に同時に出たりして戸惑う場合があります。理解するには現在のファイル、次のコミットに含める内容、最後のコミットを分けて考える必要があります。git statusはその差を読む基本ツールです。

ここでは一般的なGitリポジトリで変更・ステージング・未追跡ファイルを区別する方法を説明します。コマンドと出力は理解用の架空例で、読者の実リポジトリでの実行結果ではありません。変更を消すコマンドから始めず、まず状態と差を確認する手順に集中します。

1. 作業ディレクトリ、ステージング領域、コミットを区別する

作業ディレクトリは、エディターで現在読み修正するファイルがある空間です。ステージング領域は次のコミットに含める内容をまとめた状態で、インデックスとも呼びます。最後のコミットは既に記録したスナップショットです。git statusはこれらの状態間の差や未追跡ファイルなどを示します。保存ボタンを押したこととGitコミットへ記録したことは異なります。

git addは現在の変更内容を次のコミットに含める準備をする動作です。準備後に同じファイルを再修正すると、ステージング領域と現在のファイルが異なる場合があります。一ファイルがコミットする変更一覧と未ステージの変更一覧に同時に出ることもあります。エラーと即断せず、それぞれの差を確認する必要があります。

架空のnote.txtに最初の文を書いてステージした後、二番目の文を加えたとします。次のコミット用に準備したのは最初の段階のファイルで、作業ディレクトリには追加文があります。二番目も今回に含めるには現在の変更を確認して再ステージする必要があります。ファイル名があるだけで、その最新内容全体が準備済みとは限りません。

2. リポジトリの場所を確認して基本状態を読む

まずターミナルが正しいプロジェクト内にあるか確認します。別フォルダーで実行すると意図した状態を見られない場合があります。Gitリポジトリではないというエラーなら、すぐ新規リポジトリを作るより現在パスと元のプロジェクトフォルダーを確認してください。既にGit履歴があるなら、その場所で状態を読むことが先です。

基本コマンドはgit statusです。一般出力では現在ブランチ、準備済み変更、未準備変更、未追跡ファイルなどの一覧を読めます。言語、設定、進行中の作業で文言が違う場合があるため一覧の意味を確認します。本記事の英語表現が自分の画面と違っても、機能が変わったと判断する必要はありません。

架空の出力の「Changes to be committed」は次のコミット用に準備した変更、「Changes not staged for commit」は現在ファイルと準備内容間の変更、「Untracked files」はまだGitが追跡しないファイルを示します。一覧のファイルを開いて今回に含める変更を決めてください。全ファイルを一括追加する前に目的を確認するとよいでしょう。

git status
git diff
git diff --cached

上の三コマンドは状態と差を読む基本例です。git diffは通常、未ステージの変更を、git diff --cachedは最後のコミットと比較したステージ内容を確認するため使います。詳細な動作とオプションは現在のGit公式文書で確認します。

一般的な一覧	意味	最初の確認
コミットする変更	次のコミット用に準備した内容	git diff --cachedで実内容を確認
未ステージの変更	現在ファイルと準備内容の差	git diffで確認
未追跡ファイル	まだインデックスへ追加していないファイル	必要なソースか一時・生成ファイルか確認
競合関連の状態	マージ過程で整理が必要な項目	競合内容と進行中の作業を先に確認

3. 短い出力の二欄は異なる比較

git status --shortではファイル前に二文字の状態が現れます。一般的な非競合状況で最初の欄Xはインデックス、二番目の欄Yは作業ディレクトリの状態を示します。同じMでも位置で意味が違います。空白も意味を持つため、二欄を一文字のようにまとめて読みません。

架空の出力「M app.py」は最初の欄にMがある例、「 M app.py」は二番目の欄にMがある例です。「MM app.py」なら準備済み変更と、その後の作業ディレクトリ変更が併存する場合があります。この状態でコミットしても現在ファイルの全変更が自動で含まれるとは考えず、ステージ差分を直接確認する必要があります。

未追跡ファイルは??で表示されます。Aは追加、Dは削除、Rは名前変更などを示す場合があります。マージ競合中は同じ二欄も別規則で解釈するため、一般規則だけで読みません。Uやunmergedの案内が見えたら公式状態表と競合解決案内を確認し、進行作業から把握します。

架空の短い出力	一般的な非競合状況での解釈	確認する差
M app.py	変更内容がステージ済み	コミット用に準備した変更
M app.py	作業ディレクトリで修正済み	まだ準備していない変更
MM app.py	ステージ後に追加修正あり	二種類の変更をそれぞれ確認
A new.txt	新規ファイルがステージ済み	ファイル内容と含める目的
?? temp.txt	未追跡ファイル	追跡するか無視するか判断

4. 新規ファイルが見えない場合の確認

新規ファイルが一覧にないなら、実際に保存したかとプロジェクトパスを先に確認します。次に無視規則に含まれるか調べられます。.gitignoreに該当するファイルは通常、未追跡一覧から除外されます。出力オプションや設定が未追跡ファイルを隠す場合もあるため、現在のコマンドと設定を確認する必要があります。

無視規則はファイル目的を基準に判断します。ビルド結果、キャッシュ、環境別設定などはプロジェクト方針で除外できます。逆に必要なソースが意図せず無視されたなら規則をレビューする必要があります。新規ファイルが見えないからと無視ファイル全体を強制追加するより、関係する規則とファイルを調べる方がよいでしょう。

追跡中ファイルは.gitignoreへ名前を書いても自動で追跡から外れません。既に記録したファイルと未追跡ファイルでは扱いが違います。機密値のあるファイルを誤追跡したなら、一覧から隠すだけで過去履歴の露出問題が解決するとは考えてはいけません。状況に合うリポジトリ管理と該当資格情報への対処が必要な場合があります。

5. 一ファイルを読んで準備する小さな順序

架空の作業でapp.pyだけ修正したなら、まずgit statusで状態を確認し、git diff -- app.pyで変更を読みます。必要な変更と確認後、git add -- app.pyで準備できます。続いてgit diff --cached -- app.pyで次のコミット内容が合うか読み、再びgit statusを確認します。

この順序は新規ファイルや大きな作業でも基本原理が同じです。ただし新規内容、生成物、複数ファイルの依存関係も見る必要があり得ます。ファイル別に準備しても機能が分離するわけではないため、一機能に必要な変更群を考えます。別作業の変更まで含めないよう範囲も確認してください。

コミット前は変更内容を確認し、該当機能に必要な検証を実施します。statusがきれいでもテスト合格を意味しません。コミット済みでも実行結果の正確さは保証されません。状態確認は記録内容を管理する段階で、機能確認は要求動作を行うか判断する別段階です。

6. よく混同する三つの状況

第一にエディターで保存しても未ステージなら準備済み変更はない場合があります。第二にステージ後に再修正すると二一覧へ同時に出る場合があります。第三に未追跡の新規ファイルはコミット前に追加しなければ今回に含まれません。いずれもファイル名だけより、インデックスと現在内容の差を見ると理解しやすくなります。

架空のチーム作業で他の人の作成ファイルが状態一覧にあっても、すぐ自分の変更と判断しません。誰がどの作業を進め、現在のチェックアウトにどの変更があるか確認します。状態をきれいにするため一覧の変更を削除・復元すると必要作業を失い得ます。一覧は削除対象ではなく現在作業の理解資料です。

マージ、リベース、競合整理などの進行作業は通常の修正と区別します。statusの進行状況と関連ファイルを読み、段階を把握します。意味不明のまま案内の操作を連続実行するより、目的と保管する変更を先に確認してください。読み取りコマンドによる確認は次の選択の根拠を作ります。

コミット前に残す短い記録

「現在ブランチ、今回に含めるファイル、ステージ差分確認、機能検証結果、まだ未準備の変更」をメモすると次の作業へ進みやすくなります。二一覧にあるファイルは後の修正内容を記します。含めない変更が残っていても意図した状態なら理由を記録できます。

覚える要点は三つです。ファイル保存は現在ファイルの保存、git addは次のコミット準備、コミットは準備内容を記録する段階です。git statusの各一覧と二欄の意味を結び付ければ、新規・修正ファイルの状態を区別して必要変更を慎重に記録できます。

公式資料と確認範囲

• Git公式git-status文書
• Pro Git：リポジトリへの変更の記録

資料確認日：2026年10月5日。AIが公式資料を確認して作成しました。本文の架空の事例と計算例は実際のユーザー記録や実験結果ではありません。サービス条件・メニュー・公開資料は変わり得るため、必要条件は現在の公式案内で確認します。