【Git】addの取り消し方法｜restore –staged・reset HEAD・ハンク単位unstage完全ガイド

「git add .で不要なファイルまでステージしてしまった」「1つのファイルの中で、コミットしたい変更とそうでない変更を混ぜてadd してしまった」——git addの取り消しは日常的に必要になる操作です。幸いこれは破壊的な操作ではなく、ステージング（index）から作業ツリーに変更を戻すだけなので、失敗してもファイルの変更自体は失われません。

この記事では、git addを取り消す（unstage）方法を状況別に整理します。Git 2.23以降の推奨コマンドgit restore --staged、昔から使われているgit reset、ファイルの一部（ハンク単位）だけ戻す方法、git addだけでなくgit rm・git mvを取り消す場合まで実務で迷わない形で解説します。

まず押さえる：git add は何をしているのか

「addの取り消し」を理解するには、Gitの3層構造を把握しておくと迷いません。

取り消しパターン早見表

状況別に使うコマンドを整理しました。Git 2.23以降はgit restore --stagedが推奨、互換性のためgit reset系も記載しています。

推奨：git restore –staged でaddを取り消す

Git 2.23で導入されたgit restoreはファイル復元専用コマンドで、--stagedオプションを付けるとindexから指定ファイルを取り消します。作業ツリーは触らないので、ステージだけを戻す本命コマンドです。

# 特定ファイルのaddを取り消す
git restore --staged config.py

# 複数ファイルを指定
git restore --staged src/auth.py src/utils.py

# ディレクトリ配下をまとめて
git restore --staged src/

# カレントディレクトリ以下すべて
git restore --staged .

# 状態を確認
git status
# → 「Changes not staged for commit」に戻っていればOK

全ファイルをまとめてunstage

# プロジェクト全体のaddを取り消す
git restore --staged .

# または旧コマンドでも等価
git reset HEAD
git reset   # 引数なしで全unstage（--mixedが既定）

旧来：git reset でaddを取り消す

Git 2.23以前はgit reset HEAD <file>が標準でした。機能的にはgit restore --stagedと同等で、既存のチュートリアルやスクリプトでも広く使われています。新規に書くならrestore推奨ですが、古い環境や既存の手順書ではresetのままでも問題ありません。

# 特定ファイルをunstage（--mixedが既定）
git reset HEAD config.py
# 実はHEADは省略可能
git reset config.py

# 全ファイルをunstage
git reset
git reset HEAD   # HEAD明示も可

# ディレクトリ配下をまとめて
git reset HEAD src/

ブランチ全体を戻すresetとの違い

reset全般の詳細は特定のコミットまで戻す方法やrevertとresetの違いと使い分けも参考になります。

ハンク単位でaddを取り消す（-p）

1つのファイルをgit addしたが、「このハンクはステージから外したい」と後悔することがあります。-p（patchモード）で変更の塊（ハンク）単位で取り消しを選べます。

# ハンクごとにunstageするか質問される
git restore --staged -p config.py

# 旧コマンド
git reset -p HEAD config.py

# 実行後に y/n/s/e/? を入力
#   y → このハンクをunstage
#   n → このハンクはそのまま
#   s → ハンクをさらに細かく分割
#   e → エディタで手動編集
#   q → 中止
#   ? → ヘルプ表示

新規追加ファイルのaddを取り消す特殊ケース

未追跡（untracked）だった新規ファイルをaddした場合、取り消すとそのファイルは元の「untracked状態」に戻ります。ファイル自体は作業ツリーに残り、削除はされません。

# 新規作成したファイルをaddしてしまった
touch new_feature.py
git add new_feature.py
git status
# → "new file: new_feature.py" が Changes to be committed に表示

# Git 2.23以降（推奨）
git restore --staged new_feature.py
# → untrackedに戻る（ファイル自体は残る）

# 旧コマンド版
git rm --cached new_feature.py
# → 同じくuntracked に戻す

削除・renameをaddしたときの取り消し

git rmで削除をステージした、git mvでrenameをステージした——これらも「add同様の操作」として扱われるため、同じコマンドで取り消せます。

# 削除をステージしたあと（git rm や rm+git add）
git rm old_file.py
git status
# → "deleted: old_file.py" が Changes to be committed

# 取り消し（indexだけ戻す）
git restore --staged old_file.py
# → 作業ツリーには old_file.py は既にないため、さらに復元したい場合は
git restore old_file.py   # --worktreeも戻してファイル自体を復元

# renameをステージした場合
git mv oldname.py newname.py
git status
# → "renamed: oldname.py -> newname.py"

# 取り消し（両ファイル名とも指定して戻す）
git restore --staged oldname.py newname.py
# 作業ツリーも戻したい場合
git restore oldname.py newname.py

削除されたファイルの復元は消したファイルを戻す方法で詳しく解説しています。

実践シナリオ

シナリオ① git add . で余計なファイルまで混ざった

# 状態確認
git status

# 全部unstage
git restore --staged .

# 本当にcommitしたいファイルだけを個別にadd
git add src/feature.py src/utils.py

# 残りは.gitignoreやskipworktreeで対応
git commit -m "feat: 新機能を追加"

シナリオ② 機密情報を含むファイルを間違えてadd した

# すぐにindexから外す
git restore --staged .env

# 今後の事故防止のため.gitignore追記
echo ".env" >> .gitignore
git add .gitignore

# 機密ファイルが除かれたことを再確認
git status
# → .env が Changes not staged for commit 側に移動していればOK

シナリオ③ 1ファイル内の一部変更だけ残したい

# ファイルのaddを一度全取り消し
git restore --staged src/api.py

# 必要な箇所だけ選びながらadd
git add -p src/api.py
# y/n/s/e で選択

# commit
git commit -m "fix: API認証の修正のみ"

# 残った変更は別コミットに
git add src/api.py
git commit -m "refactor: その他の整理"

シナリオ④ commit してしまった

addした後にcommitまで進んでしまった場合は「add取り消し」ではなく「commit取り消し」の領域です。

# 直前のcommitを取り消し、変更はindexに残す
git reset --soft HEAD~1

# さらにindexから外して作業ツリーへ
git restore --staged .

# 必要なファイルだけ選び直してadd＆commit
git add src/feature.py
git commit -m "feat: 本来入れたかった変更だけを再コミット"

commit取り消しの詳細はコミットの取り消し方を参照してください。

GUI・IDEでのunstage方法

コマンドラインが苦手ならIDEのGUI操作でも同じことができます。

やってはいけない落とし穴

git reset –hard でaddを取り消そうとする

git reset --hardはコミット単位の戻し方であり、ファイルを指定せずに実行すると作業ツリーの未コミット変更すべてを破棄します。addを取り消したいだけならgit restore --staged <file>またはgit reset HEAD <file>で十分です。--hardで消えた変更はreflogにも残らないため、復元は不可能です。

git rm で取り消そうとして実ファイルも消す

git rm <file>（--cachedなし）は作業ツリーのファイルも削除します。add の取り消しではなく「ファイル削除をステージ」という別の操作です。未追跡ファイルのaddを取り消すならgit rm --cached <file>またはgit restore --staged <file>を使ってください。

revert で add を取り消そうとする

旧記事でもよく見る誤解ですが、git revertはコミット済みの変更を打ち消すコマンドで、「addの取り消し」には使いません。addはまだコミット前の段階なので、そもそもrevertの対象になりません。コミット後ならrevert／reset --soft HEAD~1を使い分けます。詳しくはコミットの取り消し方を参照。

git reset と git reset HEAD の違いを取り違える

git reset（引数なし）は「全ファイルをunstage」、git reset HEADも同じ挙動、git reset HEAD <file>は「指定ファイルだけunstage」、git reset HEAD~1は「直前のコミットを取り消し」と、引数によって意味が変わります。「ファイル名を付けたかどうか」で挙動が全く異なる点に注意してください。

addの取り消しで作業ツリーも戻したつもりになる

git restore --staged <file>はあくまで「indexを戻す」だけで、作業ツリーのファイル内容は変えません。「編集自体も取り消したい」ならgit restore <file>（--worktree側）を別途実行するか、git restore --staged --worktree <file>で同時処理します。後者はファイル内容も巻き戻す破壊的操作なので、編集の消失リスクを理解して使ってください。

よくある質問

関連記事

• 【Git】addしたファイルの変更を確認する方法 — add済みの内容を確認してから取り消すとミスが減る
• 【Git】管理からファイルを外す方法 — 追跡自体を外したい場合（rm –cached）
• 【Git】コミットの取り消し方 — addしてcommitまでしてしまった場合
• 【Git】pushを取り消す方法 — push後の対処
• 【Git】特定のコミットまで戻す方法 — reset全般の詳細
• 【Git】revertとresetの違いと使い分け — 概念の深掘り
• 【Git】消したファイルを戻す方法 — 削除のaddを取り消した後のファイル復元
• 【Git】履歴に含まれる機密情報を完全に削除する方法 — 機密情報をpushしてしまった緊急時

まとめ

• addの取り消しはindexを戻すだけ——作業ツリーの変更は消えない安全な操作
• Git 2.23以降の推奨：git restore --staged <file>
• 旧コマンド：git reset HEAD <file>（機能は同じ）
• 全ファイル一括ならgit restore --staged .またはgit reset
• ハンク単位は-pオプションで選択的にunstage
• 新規ファイルはrestore --stagedかrm --cachedでuntrackedに戻せる
• git reset --hardは絶対に使わない——ファイルの変更が失われる
• コミット後なら「commit取り消し」、push後なら「push取り消し」の領域へ

addの取り消しは、Gitの3層構造（作業ツリー／index／HEAD）を理解していれば怖くない操作です。indexはHEADと作業ツリーの間のただの「仮置き場」であり、仮置きしたものを戻すだけなので失敗してもやり直せます。GUIツール・git add -p・restore --stagedを使い分けて、きれいな粒度でコミットを組み立てる習慣を付けましょう。それがレビューしやすく、後から履歴を読み返しやすい、質の高いGit運用への第一歩です。