「あっ、間違ったファイルをgit addしちゃった…」
Gitでファイルをステージング（git add）した後、「このファイルは含めたくなかった」と気づくこと、ありますよね。
特にgit add .で全部追加してしまった時は焦ります。
でも安心してください！Gitにはステージングを取り消す方法がちゃんと用意されています。
今回は、git addの取り消し方法を状況別に詳しく解説していきます！
まず理解しておきたい：Gitの3つのエリア
ステージングの取り消しを理解するには、Gitの基本的な仕組みを知っておく必要があります。
Gitの3つの領域
Gitでは、ファイルは以下の3つのエリアを移動します：
①ワークツリー → ②ステージングエリア → ③リポジトリ
(作業ディレクトリ) (インデックス) (コミット履歴)①ワークツリー（Working Tree）
- 実際にファイルを編集する場所
- あなたがコードを書いている場所
②ステージングエリア（Staging Area / Index）
- コミット候補のファイルを置く場所
git addで追加される- 「まな板の上に材料を並べる」イメージ
③リポジトリ（Repository）
- コミットされた履歴が保存される場所
git commitで保存される
ステージングの取り消しとは？
【現在の状態】
ワークツリー（変更あり） → ステージングエリア（git add済み）
【取り消し後】
ワークツリー（変更あり） ← ステージングエリア（空）重要： ステージングを取り消しても、ファイルの変更内容は残ります。
あくまで「コミット候補から外すだけ」なので、安心して使えます。
状況に応じた3つの取り消し方法
Gitのバージョンやコミット履歴の有無によって、使うコマンドが異なります。
方法の選び方
【判断フロー】
1. Git 2.23以降を使っている？
YES → git restore --staged（推奨）
NO → 2へ
2. 過去にコミットしたことがある？
YES → git reset HEAD
NO → git rm --cachedそれでは、それぞれの方法を詳しく見ていきましょう！
【方法1】git restore –staged（最新・推奨）
Git 2.23以降で使える、最も推奨される方法です。
基本的な使い方
特定のファイルのステージングを取り消す
git restore --staged ファイル名例： index.htmlのステージングを取り消す
git restore --staged index.html複数のファイルを指定する
git restore --staged index.html style.css main.jsスペースで区切って複数指定できます。
すべてのステージングを取り消す
git restore --staged ..（ドット）は「現在のディレクトリ以下すべて」という意味です。
実際の操作例
# ファイルを編集
echo "新しい内容" > index.html
# ステージングに追加
git add index.html
# 状態を確認
git status
# → Changes to be committed:
# modified: index.html
# ステージングを取り消す
git restore --staged index.html
# 再度状態を確認
git status
# → Changes not staged for commit:
# modified: index.htmlなぜこの方法が推奨されるのか？
1. コマンド名が分かりやすい
restore（復元）という言葉から、何をするか想像しやすい--stagedで「ステージングエリアを操作する」と明確
2. 安全性が高い
- 特定の用途に特化している
- 誤って履歴を書き換える危険性が低い
3. Gitの公式推奨
- 新しいGitでは
git statusでも推奨される - 今後のスタンダードになる
【方法2】git reset HEAD（従来の方法）
Git 2.23より前のバージョンや、従来の方法に慣れている方向けです。
基本的な使い方
すべてのステージングを取り消す
git reset HEADまたは単に：
git resetHEADは省略可能です。
特定のファイルのステージングを取り消す
git reset HEAD ファイル名例：
git reset HEAD index.html複数ファイルを指定する
git reset HEAD index.html style.cssディレクトリごと取り消す
git reset HEAD src/HEADって何？
HEADは「現在のコミット」を指す特別な名前です。
git reset HEADは「現在のコミットの状態にリセットする」という意味になります。
実際の操作例
# 複数のファイルをステージング
git add index.html style.css main.js
# 状態確認
git status
# → Changes to be committed:
# modified: index.html
# modified: style.css
# modified: main.js
# すべてのステージングを取り消す
git reset HEAD
# 再確認
git status
# → Changes not staged for commit:
# modified: index.html
# modified: style.css
# modified: main.jsresetとrestoreの違い
git reset：
- 多機能で強力
- ステージング以外にもコミット履歴の操作も可能
- 使い方を間違えると危険
git restore：
- ステージング操作に特化
- 用途が明確で安全
- 新しいバージョンでの推奨方法【方法3】git rm –cached（初回コミット前）
まだ一度もコミットしていない状態（git init直後）で使います。
いつ使うのか？
【この状況】
1. git initでリポジトリを作成
2. git addでファイルを追加
3. まだ一度もgit commitしていない
【この時に使う】
git rm --cached基本的な使い方
特定のファイルを取り消す
git rm --cached ファイル名例：
git rm --cached secret.txtすべてのファイルを取り消す
git rm --cached -r .-rオプションは「再帰的に」という意味で、ディレクトリ内すべてを対象にします。
複数ファイルを指定する
git rm --cached file1.txt file2.txt実際の操作例
# 新しいリポジトリを作成
git init
# ファイルを追加
git add index.html style.css
# 状態確認
git status
# → Changes to be committed:
# new file: index.html
# new file: style.css
# index.htmlだけ取り消す
git rm --cached index.html
# 再確認
git status
# → Changes to be committed:
# new file: style.css
# → Untracked files:
# index.htmlなぜ初回だけ違うコマンド？
初回コミット前はHEAD（現在のコミット）が存在しません。
そのため、git reset HEADは使えず、代わりにgit rm --cachedを使います。
注意：コミット後に使うと危険！
⚠️ 重要： すでにコミットしたファイルにgit rm --cachedを使うと、次のコミットでそのファイルが削除されます！
# ❌ 危険な例（コミット後に実行）
git rm --cached important.txt
git commit -m "commit"
# → important.txtがリポジトリから削除されるコミット後は必ずgit restore --stagedかgit reset HEADを使いましょう。
よくある使用シーン別の対処法
実際の開発でよくあるケースと、その対処法を見ていきましょう。
シーン1：git add .で全部追加してしまった
# 全部ステージングしてしまった
git add .
# 特定のファイルだけ取り消す
git restore --staged config.json secret.env
# または特定のファイル以外すべて取り消す
git restore --staged .
git add index.html style.css # 必要なものだけ再度追加シーン2：.gitignoreの設定前にファイルを追加した
# 状況：node_modules/をステージングしてしまった
# ステージングを取り消す
git restore --staged node_modules/
# .gitignoreに追加
echo "node_modules/" >> .gitignore
# .gitignoreをステージング
git add .gitignoreシーン3：間違ったブランチでgit addした
# 現在のブランチを確認
git branch
# → * feature-a （間違えた！）
# ステージングを取り消す
git restore --staged .
# 正しいブランチに移動
git checkout feature-b
# あらためてステージング
git add .シーン4：一部のファイルだけコミットしたい
# たくさんのファイルを編集した
# でも今回は一部だけコミットしたい
# まず全部ステージング
git add .
# 不要なものを取り消す
git restore --staged test.html debug.js
# 状態確認
git status
# コミット
git commit -m "必要な変更のみコミット"シーン5：設定ファイルを間違えて追加した
# 機密情報が含まれるファイルを追加してしまった
git add config/database.yml
# すぐに取り消す
git restore --staged config/database.yml
# .gitignoreに追加
echo "config/database.yml" >> .gitignore
git add .gitignoreステージング取り消しとファイル削除の違い
混同しやすいので、しっかり区別しておきましょう。
ステージングの取り消し（今回の内容）
git restore --staged index.html何が起こる：
- ステージングエリアから除外される
- ファイルの変更内容は残る
- ワークツリーは影響を受けない
結果：
Before: 変更あり（ステージング済み）
After: 変更あり（ステージング前）ファイルの変更を破棄
git restore index.html何が起こる：
- ファイルの変更内容が失われる
- 最後のコミットの状態に戻る
- 元に戻せない！
結果：
Before: 変更あり
After: 変更なし（最後のコミットと同じ）対比表
| コマンド | ステージング | ファイルの変更 | 危険度 |
|---|---|---|---|
git restore --staged | 取り消される | 残る | 安全 |
git restore | – | 破棄される | 危険 |
git reset HEAD | 取り消される | 残る | 安全 |
git reset --hard | 取り消される | 破棄される | 非常に危険 |
git statusでの確認方法
ステージングの状態を確認するのはgit statusコマンドです。
ステージング済みのファイル
git status結果：
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: index.html
new file: style.cssChanges to be committed:の下に表示されるファイルがステージング済みです。
ステージングしていない変更
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: main.jsChanges not staged for commit:の下がステージングしていない変更です。
追跡していないファイル
Untracked files:
(use "git add <file>..." to include in what will be committed)
new-file.txtUntracked files:は新規作成したファイルで、まだGitの管理下にないファイルです。
取り消し前後の比較
# ステージング前
git add index.html
git status
# → Changes to be committed:
# modified: index.html
# 取り消し後
git restore --staged index.html
git status
# → Changes not staged for commit:
# modified: index.htmlトラブルシューティング
よくある問題と解決方法です。
Q1：git restore –stagedが使えない
症状：
git restore --staged index.html
# → git: 'restore' is not a git command原因： Gitのバージョンが古い（2.23より前）
解決方法：
# 代わりにgit resetを使う
git reset HEAD index.html
# またはGitをアップデート
git --version # バージョン確認Q2：全部取り消したのにまだ表示される
症状：
git restore --staged .
git status
# → まだファイルが表示される原因： ステージングは取り消されたが、ファイル自体は変更されたまま
解決方法：
# これは正常です！
# 「Changes to be committed」が「Changes not staged for commit」に変わっていればOKQ3：間違えてgit restoreを実行してしまった
症状：
# --stagedを付け忘れた！
git restore index.html
# → ファイルの変更が消えた！原因： --stagedなしのgit restoreは変更を破棄する
解決方法：
# エディタで「元に戻す」（Ctrl+Z / Cmd+Z）が使えれば戻せる
# それ以外は残念ながら復元不可能...
# 予防策：
# - こまめにコミットする
# - 重要な作業前はブランチを作るQ4：git rm –cachedしたらファイルが消えた
症状：
# コミット後にgit rm --cachedを実行
git rm --cached important.txt
ls
# → ファイルがない！原因： コミット後のファイルにgit rm --cachedは使えない
解決方法：
# まだコミットしていなければ：
git reset HEAD important.txt
# すでにコミットしてしまった場合：
git revert HEAD # コミット自体を取り消すQ5：特定のファイルだけ常に無視したい
症状： 毎回同じファイルのステージングを取り消している
解決方法： .gitignoreに追加する
# .gitignoreに追加
echo "config/local.yml" >> .gitignore
echo "*.log" >> .gitignore
echo "node_modules/" >> .gitignore
# すでにステージングされている場合は取り消す
git restore --staged config/local.yml
# .gitignore自体をコミット
git add .gitignore
git commit -m ".gitignoreを追加"便利なTips
Tip1：エイリアスで短縮コマンドを作る
毎回長いコマンドを打つのは面倒ですよね。
# 短縮コマンドを設定
git config --global alias.unstage 'restore --staged'
# これで使える
git unstage index.html
# ↑ git restore --staged index.html と同じTip2：VSCodeでGUIで操作する
VSCodeのSource Controlビューでは、GUIでステージングを取り消せます。
1. VSCodeの左サイドバーでSource Controlアイコンをクリック
2. 「Staged Changes」にあるファイルの「-」ボタンをクリック
3. ステージングが解除されるTip3：SourceTreeやGitKrakenなどのGUIツール
GUIツールを使えば、クリックでステージングを操作できます。
SourceTree:
1. ファイルステータスを表示
2. ステージング済みのファイルを選択
3. 「Unstage」ボタンをクリックGitKraken:
1. Unstage Files領域を表示
2. ファイルをドラッグ＆ドロップで移動Tip4：git addの前に.gitignoreを設定する
そもそもステージングの取り消しを減らすコツです。
# プロジェクト開始時にまず.gitignoreを作成
cat > .gitignore << EOF
node_modules/
*.log
.env
.DS_Store
EOF
# それからgit add
git add .まとめ：状況別コマンド早見表
最後に、すぐに使える早見表をまとめます。
基本的な取り消し方法
| 状況 | コマンド | 説明 |
|---|---|---|
| Git 2.23以降（推奨） | git restore --staged ファイル名 | 最も分かりやすい |
| Git 2.23以降（全部） | git restore --staged . | すべて取り消す |
| Git 2.22以前 | git reset HEAD ファイル名 | 従来の方法 |
| Git 2.22以前（全部） | git reset HEAD | すべて取り消す |
| 初回コミット前 | git rm --cached ファイル名 | 初回専用 |
| 初回コミット前（全部） | git rm --cached -r . | すべて取り消す |
シーン別の対処法
| シーン | 対処法 |
|---|---|
| git add .で全部追加 | git restore --staged .必要なものだけ再度 git add |
| 設定ファイルを誤追加 | git restore --staged 設定ファイル.gitignoreに追加 |
| 一部だけコミットしたい | git restore --staged 不要なファイル |
| 間違ったブランチで作業 | git restore --staged .正しいブランチに移動 git add . |
よくある質問
Q：ファイルの変更内容は消える？
A：消えません！ステージングから外れるだけです。
Q：どのコマンドを使えばいい？
A：Git 2.23以降ならgit restore --stagedを使いましょう。
Q：間違えて実行しても戻せる？
A：ステージングの取り消しは安全に戻せます。ファイルの変更は残っているので。
Q：コミット後でも使える？
A：使えます。ただしgit rm --cachedはコミット後は使わないでください。
覚えておきたいポイント
- ステージングの取り消しは安全
- ファイルの変更内容は残る
- 何度でもやり直せる
- 推奨コマンドは
git restore --staged
- 分かりやすい
- 安全性が高い
- 公式推奨
git statusで必ず確認
- 取り消す前に確認
- 取り消した後も確認
- こまめに確認する習慣を
- 間違えやすいコマンドに注意
git restore（–stagedなし）は変更を破棄git rm --cachedはコミット後は危険
Gitのステージング取り消し、理解していただけましたでしょうか？
最初は難しく感じるかもしれませんが、実際に試してみれば意外と簡単です。
練習用のリポジトリを作って、色々な取り消し方を試してみてくださいね！
安心してgit addを使えるようになると、Gitがもっと便利になりますよ！
コメント