1. はじめに
Git で開発していると、「git add . を実行した後に、実はコミットしたくないファイルが含まれていた」という経験はありませんか？私はよくあります。手癖でついつい「git add .」してしまいます。
この記事では、git add . でステージングした変更を安全に取り消す（アンステージする）方法を記録します。
何度かググるので、自分の記録です。
2. ステージングエリアとは
まず、Git のステージングエリア（インデックス）について簡単に説明します。
ワーキングツリー → ステージングエリア → リポジトリ
↑ ↑ ↑
ファイル編集 git add git commit
fallback
- ワーキングツリー: 実際に編集しているファイル
- ステージングエリア: コミット予定のファイルが置かれる場所
- リポジトリ: コミット済みのファイル履歴
git add . は、変更されたすべてのファイルをワーキングツリーからステージングエリアに移動する操作です。
3. アンステージの基本的な方法
git add . でステージングした変更を取り消すには、主に2つの方法があります。
3.1. git reset を使う方法（従来の方法）
# カレントディレクトリ以下の全ファイルのステージングを取り消す
git reset HEAD .
bash
動作説明：
- 現在の
HEAD（最後にコミットした状態）を基準にステージングエリアをリセット - ワーキングツリー（実際のファイル）は変更されず、「ステージから外す」だけ
- Git のすべてのバージョンで利用可能
個別ファイルの場合：
git reset HEAD path/to/file.ext
bash
3.2. git restore を使う方法（Git 2.23以降）
# カレントディレクトリ以下の全ファイルのステージングを取り消
bash
動作説明：
- 名前の通り「ステージ（
--staged）からの復元」を実行 - ワーキングツリーには触れず、ステージングエリアのみをクリア
- より直感的でわかりやすいコマンド名
個別ファイルの場合：
git restore --staged path/to/file.ext
bash
4. 実用的な使用例
4.1. 例1: 全てのステージングを取り消し
# 多数のファイルを誤ってステージング
git add .
# ステータス確認
git status
# 全てのステージングを取り消し
git restore --staged .
# 再度ステータス確認
git status
bash
4.2. 例2: 特定のファイルのみアンステージ
# 複数ファイルをステージング
git add file1.txt file2.txt config.json
# config.json のみアンステージ
git restore --staged config.json
# 残りのファイルはステージングされたまま
git status
bash
4.3. 例3: 新規ファイルのアンステージ
# 新規ファイルをステージング
git add new-feature.js
# 新規ファイルをアンステージ
git restore --staged new-feature.js
# ファイルは未追跡状態に戻る
git status
bash
5. 状況別の使い分け
5.1. 全てのステージングを取り消したい場合
# 新しい方法（推奨）
git restore --staged .
# 従来の方法
git reset HEAD .
bash
5.2. 特定のファイルパターンのみアンステージ
# .log ファイルのみアンステージ
git restore --staged "*.log"
# 特定のディレクトリのみ
git restore --staged src/components/
bash
5.3. 一部のファイルを選択的にアンステージ
# 対話的にファイルを選択
git add -i
# 選択画面で "3: revert" を選択してアンステージ
bash
6. git reset の詳細オプション
git reset には複数のモードがあり、理解しておくと便利です。
6.1. reset のモード
| モード | 説明 | ステージング | ワーキングツリー |
|---|---|---|---|
--soft |
HEADのみ移動 | 保持 | 保持 |
--mixed（デフォルト） |
HEAD + ステージング | リセット | 保持 |
--hard |
HEAD + ステージング + ワーキング | リセット | リセット |
アンステージに使用する場合：
# これらは同じ動作
git reset HEAD .
git reset --mixed HEAD .
bash
7. よくある問題と解決法
7.1. Q1: 「pathspec ‘.’ did not match any files」エラー
原因： まだコミットが存在しない（初回コミット前）
解決法：
# 初回コミット前の場合
git rm --cached .
# または個別ファイル
git rm --cached filename.txt
bash
7.2. Q2: アンステージ後にファイルが消えた
原因： git reset --hard を誤って使用した
対処法：
# 作業を確認
git status
# ワーキングツリーの変更が消えた場合は復元困難
# バックアップがあれば復元
bash
7.3. Q3: 一部のファイルだけアンステージしたい
解決法：
# 方法1: 個別指定
git restore --staged file1.txt file2.txt
# 方法2: パターン指定
git restore --staged "*.tmp"
# 方法3: 対話モード
git add -i
bash
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 # 最後のコミットをアンステージ
bash
9. ベストプラクティス
9.1. ステージング前の確認
# ステージング前に変更を確認
git status
git diff
# 必要なファイルのみステージング
git add file1.txt file2.txt
# 全体をステージングする場合は慎重に
git add .
bash
9.2. 段階的なステージング
# 機能ごとに分けてステージング
git add src/feature1/
git commit -m "Add feature1"
git add src/feature2/
git commit -m "Add feature2"
bash
9.3. .gitignore の活用
不要なファイルをあらかじめ除外：
# ビルド成果物
build/
dist/
*.log
# IDE設定
.vscode/
.idea/
# 一時ファイル
*.tmp
*.swp
fallback
9.4. ステージングの可視化
# ステージングされたファイルを確認
git diff --cached
# ステージングと作業ディレクトリの両方を確認
git diff HEAD
bash
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の機能を活用していきましょう。
