git add . を取り消す方法：ステージングを安全にアンステージする

🗓 2025-07-13

1. はじめに

Git で開発していると、「git add . を実行した後に、実はコミットしたくないファイルが含まれていた」という経験はありませんか？私はよくあります。手癖でついつい「git add .」してしまいます。この記事では、git add . でステージングした変更を安全に取り消す（アンステージする）方法を記録します。

何度かググるので、自分の記録です。

2. ステージングエリアとは

まず、Git のステージングエリア（インデックス）について簡単に説明します。

ワーキングツリー → ステージングエリア → リポジトリ
     ↑                ↑               ↑
  ファイル編集        git add        git commit

ワーキングツリー: 実際に編集しているファイル
ステージングエリア: コミット予定のファイルが置かれる場所
リポジトリ: コミット済みのファイル履歴

git add . は、変更されたすべてのファイルをワーキングツリーからステージングエリアに移動する操作です。

3. アンステージの基本的な方法

git add . でステージングした変更を取り消すには、主に2つの方法があります。

3.1. git reset を使う方法（従来の方法）

# カレントディレクトリ以下の全ファイルのステージングを取り消す
git reset HEAD .

動作説明：

現在の HEAD（最後にコミットした状態）を基準にステージングエリアをリセット
ワーキングツリー（実際のファイル）は変更されず、「ステージから外す」だけ
Git のすべてのバージョンで利用可能

個別ファイルの場合：

git reset HEAD path/to/file.ext

3.2. git restore を使う方法（Git 2.23以降）

# カレントディレクトリ以下の全ファイルのステージングを取り消

動作説明：

名前の通り「ステージ（--staged）からの復元」を実行
ワーキングツリーには触れず、ステージングエリアのみをクリア
より直感的でわかりやすいコマンド名

個別ファイルの場合：

git restore --staged path/to/file.ext

4. 実用的な使用例

4.1. 例1: 全てのステージングを取り消し

# 多数のファイルを誤ってステージング
git add .

# ステータス確認
git status

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

# 再度ステータス確認
git status

4.2. 例2: 特定のファイルのみアンステージ

# 複数ファイルをステージング
git add file1.txt file2.txt config.json

# config.json のみアンステージ
git restore --staged config.json

# 残りのファイルはステージングされたまま
git status

4.3. 例3: 新規ファイルのアンステージ

# 新規ファイルをステージング
git add new-feature.js

# 新規ファイルをアンステージ
git restore --staged new-feature.js

# ファイルは未追跡状態に戻る
git status

5. 状況別の使い分け

5.1. 全てのステージングを取り消したい場合

# 新しい方法（推奨）
git restore --staged .

# 従来の方法
git reset HEAD .

5.2. 特定のファイルパターンのみアンステージ

# .log ファイルのみアンステージ
git restore --staged "*.log"

# 特定のディレクトリのみ
git restore --staged src/components/

5.3. 一部のファイルを選択的にアンステージ

# 対話的にファイルを選択
git add -i
# 選択画面で "3: revert" を選択してアンステージ

6. git reset の詳細オプション

git reset には複数のモードがあり、理解しておくと便利です。

6.1. reset のモード

モード	説明	ステージング	ワーキングツリー
`--soft`	HEADのみ移動	保持	保持
`--mixed`（デフォルト）	HEAD + ステージング	リセット	保持
`--hard`	HEAD + ステージング + ワーキング	リセット	リセット

アンステージに使用する場合：

# これらは同じ動作
git reset HEAD .
git reset --mixed HEAD .

7. よくある問題と解決法

7.1. Q1: 「pathspec ‘.’ did not match any files」エラー

原因： まだコミットが存在しない（初回コミット前）

解決法：

# 初回コミット前の場合
git rm --cached .

# または個別ファイル
git rm --cached filename.txt

7.2. Q2: アンステージ後にファイルが消えた

原因： git reset --hard を誤って使用した

対処法：

# 作業を確認
git status

# ワーキングツリーの変更が消えた場合は復元困難
# バックアップがあれば復元

7.3. Q3: 一部のファイルだけアンステージしたい

解決法：

# 方法1: 個別指定
git restore --staged file1.txt file2.txt

# 方法2: パターン指定
git restore --staged "*.tmp"

# 方法3: 対話モード
git add -i

8. どちらのコマンドを使うべきか

gitのバージョンの条件が満たすのであれば、git restore --stagedを使います。

8.1. git restore –staged を推奨する理由

直感的: コマンド名から動作が理解しやすい
安全: ワーキングツリーを誤って変更するリスクが低い
目的特化: ステージング操作に特化している

8.2. git reset HEAD を使う場合

互換性: 古いGitバージョンでも動作
慣習: チーム内で一般的に使用されている
多機能: 他のリセット操作と統一

8.3. 推奨される使い分け

# 日常的なアンステージ（推奨）
git restore --staged .

# 古いGitバージョンや既存プロジェクト
git reset HEAD .

# より複雑なリセット操作が必要な場合
git reset --soft HEAD~1  # 最後のコミットをアンステージ

9. ベストプラクティス

9.1. ステージング前の確認

# ステージング前に変更を確認
git status
git diff

# 必要なファイルのみステージング
git add file1.txt file2.txt

# 全体をステージングする場合は慎重に
git add .

9.2. 段階的なステージング

# 機能ごとに分けてステージング
git add src/feature1/
git commit -m "Add feature1"

git add src/feature2/
git commit -m "Add feature2"

9.3. .gitignore の活用

不要なファイルをあらかじめ除外：

# ビルド成果物
build/
dist/
*.log

# IDE設定
.vscode/
.idea/

# 一時ファイル
*.tmp
*.swp

9.4. ステージングの可視化

# ステージングされたファイルを確認
git diff --cached

# ステージングと作業ディレクトリの両方を確認
git diff HEAD

10. まとめ

git add . の取り消し方法をまとめると：

基本的な方法：

新しい方法: git restore --staged .（推奨）
従来の方法: git reset HEAD .

選択のポイント：

Git 2.23以降なら git restore --staged が直感的
古いバージョンやチーム慣習に合わせて git reset HEAD
どちらも結果は同じなので、一貫性を重視

安全に使用するために：

ステージング前に git status で確認
不要なファイルは .gitignore で除外
段階的にコミットして変更を整理
アンステージ後は git status で状態確認

これらの操作を覚えることで、より安全で効率的なGitワークフローを構築できます。間違いを恐れずに、積極的にGitの機能を活用していきましょう。