git addの取り消し方｜1ファイル・全部・commit後の早見表と復元

git add は作業ツリーの変更を「ステージ」に載せる操作で、取り消しはそこから外すだけです。

flowchart TD
    W["作業ツリー<br>編集したファイル"] -- "git add" --> I["ステージ<br>次のコミットに入れる予約"]
    I -- "git restore --staged<br>add の取り消し" --> W
    I -- "git commit" --> H["リポジトリ<br>コミット済みの履歴"]

git restore --staged は Git 2.23（2019年8月）で加わったコマンドです。それより前の版では git reset HEAD <ファイル> を使います（結果は同じです）。

確認環境：Git 2.43.0（Linux）。使い捨てのリポジトリと、ローカルに作った bare リポジトリ（リモートの代わり）でこの記事のコマンドを実行し、git status などの出力を英語表示（LANG=C）のまま載せています。コミットIDは実行のたびに変わり、出力中のリモートのパスは <remote> と表記しています。コマンドの仕様と版の情報は Git 公式マニュアル（git-scm.com、最新版 2.56 系）と Git 2.23・2.0 のリリースノート、VS Code の操作は VS Code 公式ドキュメント、IntelliJ IDEA の操作は JetBrains の公式ヘルプ（2026.2）で確かめました（確認日 2026年10月16日）。

git add の取り消しとは何をすることか（ステージの仕組み）

Git では、変更は3つの場所を順に進みます。git add は作業ツリーの変更を「ステージ」に載せる操作で、git add の取り消しは「ステージから下ろす」操作です。ファイルそのものは作業ツリーにあるので、下ろしても編集内容は消えません。

flowchart LR
    W["作業ツリー<br>（編集したファイル）"] -- "git add" --> I["ステージ<br>（インデックス）"]
    I -- "git commit" --> H["リポジトリ<br>（HEAD）"]
    I -- "git restore --staged<br>git reset ファイル名" --> W
    H -- "git reset --soft HEAD~1" --> I
    H -- "git reset HEAD~1" --> W

ファイル1つの状態がどう移り変わるかを、git status --short の記号と合わせて描くと次のようになります。

stateDiagram-v2
    state "未追跡 ??" as U
    state "ステージ済み A / M" as S
    state "変更あり・未ステージ M" as W
    state "変更なし（追跡済み）" as C
    state "コミット済み" as H
    [*] --> U: ファイルを新規作成
    U --> S: git add
    S --> U: git restore --staged / git rm --cached
    C --> W: ファイルを編集
    W --> S: git add
    S --> W: git restore --staged / git reset
    S --> H: git commit
    H --> S: git reset --soft HEAD~1
    H --> W: git reset HEAD~1
    W --> C: git restore（変更は消える）
    H --> C: （次の編集まで）

図の「git restore（変更は消える）」だけが、編集内容を失う操作です。--staged を付けた git restore --staged はステージを下ろすだけで、ファイルには触りません。

git status --short の読み方

この記事では、状態の変化を git status --short で示しています。2文字の記号は、左がステージ、右が作業ツリーの状態です。

記号の全一覧は、関連記事「git statusの見方｜Untracked等の意味と-s短縮表示の記号一覧」で扱っています。

1ファイルだけ・フォルダだけ・全部の add を取り消す（git restore --staged）

変更したファイル1つと新規ファイル3つを git add . した状態から、順に取り消します。

$ git add .

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   .env
    modified:   app.txt
    new file:   draft.txt
    new file:   src/util.js

git status のかっこ内に、取り消しのコマンドがそのまま書かれています。

1ファイルだけ取り消す

$ git restore --staged .env

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   app.txt
    new file:   draft.txt
    new file:   src/util.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    .env

$ cat .env
DB_PASSWORD=secret

.env は Changes to be committed から Untracked files に移り、中身はそのまま残っています。git restore --staged は成功しても何も表示しません。

フォルダ以下をまとめて取り消す

$ git restore --staged src/

$ git status --short
M  app.txt
A  draft.txt
?? .env
?? src/

全部取り消す

$ git restore --staged .

$ git status
On branch main
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:   app.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    .env
    draft.txt
    src/

no changes added to commit (use "git add" and/or "git commit -a")

app.txt の変更は Changes not staged for commit に、新規ファイルは Untracked files に戻りました。. は「今いるフォルダ以下」です。サブフォルダにいる状態でリポジトリ全体を取り消すなら、git restore --staged :/（:/ はリポジトリのルートを表す書き方）か、引数なしの git reset を使います。

# sub フォルダの中で実行（mod.txt と sub/mod2.txt を add 済み）
$ git restore --staged .
$ git status --short
M  ../mod.txt
 M mod2.txt

$ git restore --staged :/
$ git status --short
 M ../mod.txt
 M mod2.txt

サブフォルダでは、git status --short のパスも今いる場所からの相対パス（../mod.txt）で表示されます。

add した後にさらに編集したファイル（MM）を取り消す

add した後に同じファイルを編集すると MM になります。このとき git restore --staged を実行しても、作業ツリーの編集内容はすべて残ります。

$ git status --short
MM app.txt

$ git diff --cached        # ステージに載っている分（line2 の追加）
diff --git a/app.txt b/app.txt
index a29bdeb..c0d0fb4 100644
--- a/app.txt
+++ b/app.txt
@@ -1 +1,2 @@
 line1
+line2

$ git diff                 # まだ載っていない分（line3 の追加）
diff --git a/app.txt b/app.txt
index c0d0fb4..83db48f 100644
--- a/app.txt
+++ b/app.txt
@@ -1,2 +1,3 @@
 line1
 line2
+line3

$ git restore --staged app.txt

$ git status --short
 M app.txt

$ cat app.txt
line1
line2
line3

git restore --staged・git reset・git rm --cached の違い

add を取り消すコマンドは3つあり、結果が同じ場面と違う場面があります。

公式マニュアルの git-reset にも、git reset <pathspec> は「git add <pathspec> の反対で、git restore --staged <pathspec> と同じ」と書かれています。

git reset で取り消す（Git 2.23 より前の版でも同じ）

$ git reset HEAD draft.txt       # 新規ファイル：何も表示されない

$ git reset app.txt              # 変更したファイル：外れた変更が表示される
Unstaged changes after reset:
M   app.txt

$ git reset                      # 引数なし：リポジトリ全体の add を取り消す
Unstaged changes after reset:
M   app.txt

$ git status --short
 M app.txt
?? .env
?? draft.txt
?? src/

HEAD は省略できます。git reset の --hard と混同しやすいのですが、パスを指定した git reset にはモード（--soft / --hard）が無く、ステージだけを変えます。 作業ツリーのファイルは変わりません。

最初のコミット前は restore --staged がエラーになる

git restore --staged は「ステージを HEAD（最新のコミット）の状態に戻す」コマンドです。コミットが1つも無いと戻し先がありません。

$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   .env
    new file:   app.txt

$ git restore --staged .env
fatal: could not resolve HEAD

$ git rm --cached .env
rm '.env'

$ git status --short
A  app.txt
?? .env

この場面では git status のヒントも git rm --cached に変わっています。git reset -- .env（引数なしの git reset なら全部）でも同じようにステージから外せることを確かめました。-- は「ここから先はファイル名」という区切りで、.env のようにブランチ名と紛らわしい名前のときに付けます。

git rm --cached はコミット済みファイルに使うと「削除」になる

add したばかりの新規ファイルに git rm --cached を使うと、restore --staged と同じ結果です。

$ git rm --cached draft.txt
rm 'draft.txt'

$ git status --short
A  .env
M  app.txt
A  src/util.js
?? draft.txt

一方、コミット済みのファイルに使うと、「Git の管理から外す」操作になり、次のコミットにファイルの削除が記録されます。

$ git rm --cached app.txt
rm 'app.txt'

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   .env
    deleted:    app.txt
    new file:   src/util.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    app.txt
    draft.txt

deleted: app.txt と Untracked files の app.txt が同時に出ています。ファイルは手元に残っていますが、このまま commit すると、他の人の手元では app.txt が消えます。間違えて実行した場合は、そのファイルに git restore --staged を使うと元に戻ります。

$ git restore --staged app.txt

$ git status --short
A  .env
 M app.txt
A  src/util.js
?? draft.txt

git rm --cached を使う本来の場面（コミット済みの .env を管理から外して .gitignore に入れる、など）は、関連記事「git rmの使い方｜--cachedで管理対象から外す方法とgit mv」で扱っています。

自分の Git の版を確かめる

$ git --version
git version 2.43.0

git status のかっこ内のヒントが git restore --staged なら 2.23 以降、git reset HEAD ならそれより前の版です。

変更の一部（hunk）だけ add を取り消す（-p）

1つのファイルの中で、片方の変更だけをコミットから外したいときは -p（--patch）を付けます。12行のファイルの1行目と12行目を書き換えて add した状態で実行しました。

$ git restore --staged -p app.txt
diff --git a/app.txt b/app.txt
index a82bf91..b6feb1a 100644
--- a/app.txt
+++ b/app.txt
@@ -1,4 +1,4 @@
-line1
+LINE1
 line2
 line3
 line4
(1/2) Unstage this hunk [y,n,q,a,d,j,J,g,/,e,?]? y
@@ -9,4 +9,4 @@ line8
 line9
 line10
 line11
-line12
+LINE12
(2/2) Unstage this hunk [y,n,q,a,d,K,g,/,e,?]? n

$ git status --short
MM app.txt

$ git diff --cached
diff --git a/app.txt b/app.txt
index a82bf91..4ebff55 100644
--- a/app.txt
+++ b/app.txt
@@ -9,4 +9,4 @@ line8
 line9
 line10
 line11
-line12
+LINE12

1つ目に y（外す）、2つ目に n（残す）と答えた結果、ステージには12行目の変更だけが残りました。git reset -p app.txt でも同じ対話になります。

add を取り消して、変更そのものも捨てる

「add を取り消す」と「変更を捨てる」は別の操作です。捨てる操作は元に戻せないので、先に git diff で中身を見ます。

$ git status --short
M  app.txt

$ git restore --staged --worktree app.txt

$ git status --short         # 何も表示されない（変更なし）

$ head -1 app.txt
line1

ステージも作業ツリーも、コミット時点（line1 だけ）に戻りました。退避してから作業する場合は次のとおりです。

$ git stash push -m "wip: app.txt"
Saved working directory and index state On main: wip: app.txt

$ git stash list
stash@{0}: On main: wip: app.txt

$ git stash pop

stash の使い方は、関連記事「git stashの使い方｜全コマンド実行結果つきで退避と復元を解説」で扱っています。未追跡ファイルの削除は、関連記事「git cleanの使い方｜未追跡ファイル削除と変更を全部取り消す手順」で扱っています。

commit した後に add を取り消す（ファイルをコミットから外す）

commit した後に「.env を入れるつもりはなかった」と気づいた場合です。push する前なら、次の3つの方法で直前のコミットから外せます。

新規ファイルを直前のコミットから外す

$ git show --stat --oneline HEAD
124b197 feat: ログイン画面を追加
 .env    | 1 +
 app.txt | 1 +
 2 files changed, 2 insertions(+)

$ git rm --cached .env
rm '.env'

$ git status --short
D  .env
?? .env

$ git commit --amend --no-edit
[main 4599882] feat: ログイン画面を追加
 Date: Fri Oct 16 10:00:00 2026 +0900
 1 file changed, 1 insertion(+)

$ git show --stat --oneline HEAD
4599882 feat: ログイン画面を追加
 app.txt | 1 +
 1 file changed, 1 insertion(+)

$ git status --short
?? .env

.env はコミットから外れ、ファイルは未追跡として手元に残りました。コミットIDが 124b197 から 4599882 に変わっています（--amend は新しいコミットで置き換える操作です）。

コミット済みファイルの変更を直前のコミットから外す

config.txt は以前からあるファイルで、今回の変更だけを外したい場合です。--source=HEAD~1 で、ステージをひとつ前のコミットの内容に戻します。

$ git show --stat --oneline HEAD
22819bf feat: 一覧画面を追加
 app.txt    | 1 +
 config.txt | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

$ git restore --source=HEAD~1 --staged config.txt

$ git status --short
MM config.txt

$ git commit --amend --no-edit
[main 30041f3] feat: 一覧画面を追加
 Date: Fri Oct 16 10:00:00 2026 +0900
 1 file changed, 1 insertion(+)

$ git status --short
 M config.txt

$ cat config.txt
debug=true

コミットは app.txt だけになり、config.txt の変更（debug=true）は作業ツリーに残っています。

reset --soft で add からやり直す

$ git reset --soft HEAD~1

$ git status --short
A  .env
M  app.txt
A  debug.log

$ git restore --staged debug.log

$ git commit -C ORIG_HEAD
[main 6537cad] feat: 一覧画面を追加
 Date: Fri Oct 16 10:00:00 2026 +0900
 2 files changed, 2 insertions(+)
 create mode 100644 .env

--soft はコミットだけを取り消し、変更をステージに残します。ORIG_HEAD には reset 前のコミットが記録されているので、-C ORIG_HEAD でそのメッセージを使い回せます。

push した後は、履歴を書き換えずに git revert で打ち消します。push 前後の取り消し方の全体は、関連記事「git commit（コミット）の取り消し方｜push前後の早見表・NG操作・復元」で扱っています。秘密情報を push してしまった場合は、履歴の書き換えより先にそのキーを無効化します。手順は関連記事「APIキーをGitHubにpushしてしまった時の対処手順」で扱っています。

git add から git commit までの基本（-A・.・-u・-p と --amend）

git add の範囲の違い（-A・.・-u）

変更・削除・新規ファイルをルートと sub フォルダに混ぜた状態で、それぞれを実行した結果です。

$ git status --short          # 実行前
 D del.txt
 M mod.txt
 M sub/mod2.txt
?? new.txt
?? sub/new2.txt

$ git add -A                  # 全体：新規・変更・削除すべて
$ git status --short
D  del.txt
M  mod.txt
A  new.txt
M  sub/mod2.txt
A  sub/new2.txt

同じ状態に戻してから -u を実行した結果です。

$ git add -u                  # 追跡済みのみ：新規ファイルは載らない
$ git status --short
D  del.txt
M  mod.txt
M  sub/mod2.txt
?? new.txt
?? sub/new2.txt

同じ状態に戻し、sub フォルダの中で git add . を実行してから、ルートで確かめた結果です。

$ cd sub
$ git add .                   # 今いるフォルダ（sub）以下だけ
$ cd ..
$ git status --short
 D del.txt
 M mod.txt
M  sub/mod2.txt
A  sub/new2.txt
?? new.txt

ルートで実行すれば git add -A と git add . は同じ結果です。公式マニュアルには、-A と -u はパスを省略すると作業ツリー全体が対象になり、以前の版ではカレントフォルダ以下に限られていたこと、フォルダを指定した git add は削除も記録すること（Git 2.0 のリリースノートでは git add <path> が git add -A <path> と同じになったとあります）が書かれています。

何が載るか先に見たいときは -n（--dry-run）を付けます。

$ git add -n .
remove 'del.txt'
add 'mod.txt'
add 'sub/mod2.txt'
add 'new.txt'
add 'sub/new2.txt'

変更の一部だけ add する（-p）

$ git add -p
diff --git a/p.txt b/p.txt
index 2f0b8ee..7c0e76b 100644
--- a/p.txt
+++ b/p.txt
@@ -1,4 +1,4 @@
-a
+A
 b
 c
 d
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? y
@@ -9,4 +9,4 @@ h
 i
 j
 k
-l
+L
(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? n

$ git status --short
MM p.txt

$ git diff --cached --stat
 p.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

1つ目だけ y と答えたので、1行目の変更だけがステージに載りました。commit の前に git diff --cached（--staged でも同じ）で、載った内容を確かめられます。

git commit の書き方

-am が新規ファイルを含まないことは、次の出力で分かります。

$ git commit -am "fix: 12行目を大文字に"
[main f33e1ae] fix: 12行目を大文字に
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git status --short
?? newfile.txt

add を忘れて commit すると、コミットは作られず、nothing added to commit と表示されます。

$ git commit -m "add z"
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    z.txt

nothing added to commit but untracked files present (use "git add" to track)

直前のコミットを直す（--amend）

$ git add newfile.txt
$ git commit --amend --no-edit
[main e954d10] fix: 12行目を大文字に
 Date: Fri Oct 16 10:00:00 2026 +0900
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 newfile.txt

$ git commit --amend -m "fix: 12行目を大文字にし、newfile.txt を追加"
[main b597a69] fix: 12行目を大文字にし、newfile.txt を追加
 Date: Fri Oct 16 10:00:00 2026 +0900
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 newfile.txt

1 file changed が 2 files changed になり、同じメッセージのまま newfile.txt が加わりました。コミットIDは amend のたびに変わります。-m を省いてメッセージを直接書くと、ファイル名として解釈されます。

$ git commit --amend "x"
error: pathspec 'x' did not match any file(s) known to git

push した後の amend は rejected になる

push 済みのコミットを amend すると、リモートと手元が別のコミットになり、push が拒否されます。

$ git commit --amend -m "fix: 12行目を大文字に（newfile.txt 追加）"
$ git status -sb
## main...origin/main [ahead 1, behind 1]

$ git push
To <remote>
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to '<remote>'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

[ahead 1, behind 1] が、amend で履歴が分かれた印です。amend をやめて元のコミットに戻すには reflog を使います。

$ git reflog -3
648d4fe HEAD@{0}: commit (amend): fix: 12行目を大文字に（newfile.txt 追加）
b597a69 HEAD@{1}: commit (amend): fix: 12行目を大文字にし、newfile.txt を追加
e954d10 HEAD@{2}: commit (amend): fix: 12行目を大文字に

$ git reset --soft "HEAD@{1}"
$ git status -sb
## main...origin/main

自分だけが使うブランチなら git push --force-with-lease で置き換えられます。共有ブランチでは amend をやめ、修正を新しいコミットとして足します。強制 push の注意点は、関連記事「git pushの使い方｜-u・rejected・強制pushの対処」で扱っています。

VS Code・IntelliJ IDEA で add を取り消す

VS Code

VS Code 公式ドキュメント「Staging, commits, and undo」での操作名と、対応する Git のコマンドです。

ドキュメントでは、Unstage は「次のコミットから変更を外したいだけのときに使う」、Discard は「コミットしていない作業を削除する」操作として区別され、Discard は元に戻せない操作として注意書きがあります。

IntelliJ IDEA

IntelliJ IDEA は既定ではステージを見せず、「チェンジリスト」でコミットに入れるファイルを選びます。JetBrains の公式ヘルプ（2026.2）では次のように説明されています。

ステージを有効にすると、エディタの変更マーカーからチャンク単位でステージできます。ステージした変更は、外部（ターミナル）で add したものも含めて、中抜きのマーカーで表示されます。

よくあるエラーと直し方

.gitignore のファイルが add されないとき

ファイル名を指定したときだけメッセージが出ます。git add . のようにフォルダで指定した場合は、何も表示されずに飛ばされます。

$ git add x.log
The following paths are ignored by one of your .gitignore files:
x.log
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"

$ git add .                # 何も表示されないが x.log は載らない

$ git check-ignore -v x.log
.gitignore:1:*.log  x.log

git check-ignore -v で、どのファイルの何行目のパターンが効いているかが分かります。逆に、すでにコミット済みのファイルは .gitignore に書いても無視されません。 git rm --cached で管理から外す必要があります。パターンの書き方と確認手順は、関連記事「.gitignoreの書き方一覧 パターン早見表と効かないときの確認手順」で扱っています。

やってはいけない操作と、戻し方

add していない変更は、どこにも記録がない

git checkout -- . で、add していない変更を消した例です。

$ git status --short
 M app.txt

$ git checkout -- .

$ git status --short         # 何も表示されない（変更なし）

$ cat app.txt
line1

$ git reflog
1d570d2 HEAD@{0}: commit (initial): init

$ git fsck --lost-found      # 何も表示されない

reflog にはコミットの移動しか記録されず、fsck も何も見つけません。add もしていない変更は、Git のどこにも保存されていないため、戻せません。 エディタの「元に戻す」やローカル履歴（VS Code の Timeline、IntelliJ の Local History）が残っていれば、そちらから戻せることがあります。

なお、git checkout -- . と git restore . は「作業ツリーをステージの内容に戻す」操作です。add 済みの変更は消えません。

$ git status --short
MM app.txt

$ git checkout -- .

$ git status --short
M  app.txt

add 済みの中身は fsck で探せる

add したファイルの中身は、Git の内部にオブジェクト（blob）として保存されています。git restore --staged --worktree で消した直後なら、どこからも参照されなくなった blob を git fsck で見つけられます。

$ git status --short
M  app.txt

$ git restore --staged --worktree app.txt

$ git fsck --lost-found
dangling blob c0d0fb45c382919737f8d0c20aaf57cf89b74af8

$ git show c0d0fb45c382919737f8d0c20aaf57cf89b74af8
line1
line2

$ git show c0d0fb45c382919737f8d0c20aaf57cf89b74af8 > app.txt

$ git status --short
 M app.txt

ファイル名は残らないので、git show で中身を見て判断します。候補が多いときは、.git/lost-found/other/ に blob のIDがファイル名として書き出されます。

誤って reset --hard したときは reflog

コミット済みのものは git reflog で戻せます。add だけしていた wip.txt と、add していない app.txt の変更がある状態で reset --hard した例です。

$ git status --short
 M app.txt
A  wip.txt

$ git reset --hard HEAD~1
HEAD is now at 1d570d2 init

$ git reflog
1d570d2 HEAD@{0}: reset: moving to HEAD~1
eeb5d38 HEAD@{1}: commit: feat: line2 を追加
1d570d2 HEAD@{2}: commit (initial): init

$ git reset --hard "HEAD@{1}"
HEAD is now at eeb5d38 feat: line2 を追加

$ git fsck --lost-found
dangling blob e7123041ee0458f44072ab4c5f267fd370f831f0

$ git show e7123041ee0458f44072ab4c5f267fd370f831f0
wip

コミット eeb5d38 は戻り、add だけしていた wip.txt の中身も見つかりました。add していなかった app.txt の変更は戻りません。HEAD@{1} は「1回前の操作のときに HEAD があった場所」で、zsh などでは {} が展開されることがあるため引用符で囲みます。reflog の見方と期限は、関連記事「git reset --hardを取り消す方法｜reflogで復元する手順」で扱っています。

迷ったときの判断表

よくある質問

Q. git add を取り消すには？ A. git restore --staged <ファイル> です。全部なら git restore --staged .、Git 2.23 より前なら git reset HEAD <ファイル> を使います。編集内容はファイルに残ります。

Q. git add の取り消しをコミット前に全部まとめてするには？ A. リポジトリのルートで git restore --staged .、またはどこにいても引数なしの git reset です。新規ファイルは未追跡（??）に戻ります。

Q. git add を取り消すと、編集した内容も消えますか？ A. 消えません。git restore --staged・git reset <ファイル>・git rm --cached はどれもステージから外すだけです。消えるのは --staged を付けない git restore <ファイル> と git checkout -- <ファイル> のほうです。

Q. git add を取り消す前にコミットしてしまいました（コミット後）。 A. push 前なら git rm --cached <ファイル>（新規ファイル）か git restore --source=HEAD~1 --staged <ファイル>（変更）の後に git commit --amend --no-edit で、直前のコミットから外せます。push 後は git revert で打ち消します。

Q. git add と git commit の違いは？ A. git add は「次のコミットに入れる変更を選ぶ」、git commit は「選んだ変更を履歴として記録する」操作です。git add だけでは履歴に残らず、git commit だけでは add していない変更は入りません（-a を付けた場合を除く）。

Q. git restore --staged と git reset HEAD はどちらを使えばよいですか？ A. 結果は同じです。Git 2.23 以降なら、役割が「戻す」に絞られていて --hard と混同しにくい git restore --staged が読みやすい書き方です。最初のコミット前は git reset か git rm --cached を使います。

Q. git rm --cached でファイルは消えますか？ A. 消えません。ステージ（Git の管理）から外れるだけで、手元のファイルは残ります。ただしコミット済みのファイルに使うと、次のコミットで「削除」として記録されるので、他の人が pull するとその人の手元からは消えます。

Q. git add -A と git add . の違いは？ A. リポジトリのルートで実行するなら同じです。サブフォルダにいるとき、-A はリポジトリ全体、. は今いるフォルダ以下だけが対象になります。

Q. git add . をしてもファイルが add されません。 A. .gitignore の対象になっていることが多いです。git check-ignore -v <ファイル> で、効いているパターンが分かります。どうしても載せるなら git add -f <ファイル> です。

Q. git commit --amend でコミットIDが変わるのはなぜですか？ A. コミットIDは内容・メッセージ・親コミット・日時から計算される値だからです。amend は元のコミットを編集するのではなく、新しいコミットを作って差し替えます。push 済みのコミットに使うと、次の push が rejected になります。

まとめ

• git add の取り消しは git restore --staged <ファイル>（全部は . か git reset）。編集内容は消えない
• 最初のコミット前は fatal: could not resolve HEAD になるので、git rm --cached か git reset <ファイル>
• git rm --cached は、コミット済みファイルに使うと「削除」がステージされる。間違えたら git restore --staged で戻る
• git restore は --staged の有無で意味が変わる。付けないと作業ツリーの変更が消え、add していなければ戻せない
• commit した後（push 前）は git rm --cached か restore --source=HEAD~1 --staged → git commit --amend --no-edit。push 後は git revert
• git add -A は全体、. は今いるフォルダ以下、-u は追跡済みのみ、-p は変更の一部だけ。-n で事前に確認できる
• reset --hard で消したコミットは git reflog、add だけしていた中身は git fsck --lost-found で探せる

参考・出典

確認日はいずれも 2026年10月16日です。

• Git 公式マニュアル git-restore：https://git-scm.com/docs/git-restore
• Git 公式マニュアル git-reset：https://git-scm.com/docs/git-reset
• Git 公式マニュアル git-rm：https://git-scm.com/docs/git-rm
• Git 公式マニュアル git-add：https://git-scm.com/docs/git-add
• Git 2.23.0 リリースノート（git switch・git restore の導入）：https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.23.0.adoc
• Git 2.0.0 リリースノート（git add の範囲の変更）：https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.0.0.adoc
• Pro Git「Git の基本 - 作業のやり直し」：https://git-scm.com/book/ja/v2/Git-の基本-作業のやり直し
• VS Code Docs「Staging, commits, and undo」：https://code.visualstudio.com/docs/sourcecontrol/staging-commits
• IntelliJ IDEA Help「Commit and push changes to Git repository」：https://www.jetbrains.com/help/idea/commit-and-push-changes.html
• IntelliJ IDEA Help「Undo changes in Git repository」：https://www.jetbrains.com/help/idea/undo-changes.html
• foojay.io「IntelliJ IDEA Changelists and Git Staging」（JetBrains Developer Advocate、Helen Scott 氏）：https://foojay.io/today/intellij-idea-changelists-and-git-staging

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。