Gitを使っていると、うっかりgit add .で必要のないファイルまでステージングしてしまったり、特定のファイルだけを追加するつもりが全て選択してしまった…という経験は誰にでもあるのではないでしょうか。とくに初心者の方にとっては「このままコミットしてしまって大丈夫なのか？」「取り消したらファイル自体が消えてしまうのでは？」と不安になる瞬間です。実はgit addの取り消しは比較的シンプルで、安全に元の状態へ戻すことができます。ただし、状況によって使うべきコマンドが異なるため、正しい知識を持っておくことが大切です。
この記事では、git addの取り消し方法を「コミット前の基本操作」から「状況別のコマンドの使い分け」、さらには「取り消し時の注意点やベストプラクティス」までわかりやすく整理しました。ターミナルでの操作はもちろん、チーム開発での安全な運用方法にも触れるので、実務でも安心して活用できます。
誤ってステージングしてしまったときに慌てず、正しい手順で安全に取り消せるようになることで、余計なエラーやチームへの迷惑を防げます。これから解説する方法を押さえておけば、「間違えてgit addしてしまった！」という状況でも落ち着いて対処できるようになります。
コミット前にできる！git addの取り消し基本操作
「あ、間違ったファイルをgit addしてしまった…」そんな時も大丈夫です。Gitでは、コミット前であれば簡単にgit addを取り消すことができます。まずは焦らず、現在の状況を確認してから適切な対処をしましょう。
git statusでステージング状況を確認する
何か操作をする前に、まずは現在の状況を把握することが重要です。git statusコマンドを使って、どのファイルがステージングエリア（コミット待ちの状態）にあるのかを確認しましょう。
$ git status実行すると、以下のような結果が表示されます：
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: index.html
new file: style.css
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: script.js
この表示から分かることは：
- 「Changes to be committed」:
git add済みで、次のコミットに含まれる予定のファイル - 「Changes not staged for commit」: 変更はあるが、まだ
git addしていないファイル
つまり、上の例ではindex.htmlとstyle.cssがgit addされた状態で、これらを取り消したい場合に以下の操作を行います。
git restore --staged の基本的な使い方
Git 2.23以降では、git restore --stagedコマンドがgit addの取り消しの標準的な方法となっています。このコマンドは直感的で分かりやすく、初心者の方にもおすすめです。
基本的な書き方：
$ git restore --staged <ファイル名>具体例：
# index.htmlのステージングを取り消す
$ git restore --staged index.html
# 複数のファイルを指定することも可能
$ git restore --staged index.html style.css
# 現在のディレクトリのすべてのステージング済みファイルを取り消す
$ git restore --staged .実行後にgit statusで確認すると、該当ファイルが「Changes not staged for commit」の欄に移動していることが分かります。
VS Codeでの操作： VS Codeを使っている場合は、ソース管理タブ（Ctrl+Shift+G）の「Staged Changes」セクションで、ファイル名の横にある「-」ボタンをクリックするだけで同じ操作ができます。
git reset HEAD <file> と git restore の違い
以前のGitバージョンや、まだ古い情報が残っているサイトではgit reset HEAD <file>というコマンドを見かけることがあります。これもgit addを取り消すコマンドですが、現在はgit restore --stagedの使用が推奨されています。
git reset HEAD <file>の例：
$ git reset HEAD index.html2つのコマンドの違いと使い分け：
| コマンド | 推奨度 | 特徴 |
|---|---|---|
git restore --staged | ★★★ | Git 2.23以降の新しいコマンド。直感的で分かりやすい |
git reset HEAD | ★★☆ | 古いバージョンでも使用可能。ただし覚えにくい |
どちらも結果は同じですが、git restore --stagedの方が：
- コマンドの意味が分かりやすい（「staged（ステージング済み）を restore（復元）する」）
- 他の
git resetコマンドとの混同を避けられる - Git公式でも推奨されている
Sourcetreeでの操作： Sourcetreeを使用している場合は、「File Status」タブの「Staged files」エリアでファイルを選択し、右クリックメニューから「Unstage」を選択することで同じ操作ができます。
重要なのは、どのコマンドを使ってもファイル自体の内容は変更されないということです。あくまで「次のコミットに含める予定のファイル一覧」から除外されるだけなので、安心して操作してください。
状況別 git add 取り消しコマンド使い分け集
実際の開発では様々な状況でgit addを取り消したくなります。ここでは、よくあるケース別に最適なコマンドを紹介します。状況に応じて適切な方法を選ぶことで、より効率的に作業を進められます。
ファイルを1つだけ取り消す：git restore --staged <ファイル名>
最もシンプルで頻繁に使う操作です。特定のファイル1つだけをgit addの対象から除外したい場合に使用します。
基本的な使い方：
$ git restore --staged <ファイル名>具体例：
# 間違えてaddしたconfig.txtを取り消す
$ git restore --staged config.txt
# パスを含むファイルも指定可能
$ git restore --staged src/components/Header.js
# 実行前の状況確認
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: index.html
modified: config.txt ← これを取り消したい
# コマンド実行
$ git restore --staged config.txt
# 実行後の確認
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: index.html
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
modified: config.txt ← ここに移動した
注意点
- ファイル名は正確に入力する必要があります
- タブ補完機能を使うと入力ミスを防げます
- ファイルの変更内容自体は保持されます
複数のファイルをまとめて取り消す：git reset
複数のファイルを一度に取り消したい場合は、いくつかの方法があります。状況に応じて使い分けましょう。
方法1：git restore --stagedで複数指定
# スペース区切りで複数のファイルを指定
$ git restore --staged file1.txt file2.txt file3.txt
# ワイルドカードも使用可能
$ git restore --staged *.css
# 特定のディレクトリ内のすべてのファイル
$ git restore --staged src/方法2：git reset（推奨）
# すべてのステージング済みファイルを一括で取り消す
$ git reset
# 特定のファイルパターンを指定
$ git reset HEAD *.js
# より明示的な書き方（結果は同じ）
$ git reset HEAD実例：
# 実行前の状況
$ git status
Changes to be committed:
modified: index.html
modified: style.css
modified: script.js
new file: config.json
# すべてを一括で取り消す
$ git reset
# 実行後の確認
$ git status
Changes not staged for commit:
modified: index.html
modified: style.css
modified: script.js
Untracked files:
config.json ← 新規ファイルは「Untracked」になる
VS Codeでの一括操作
VS Codeでは、「Staged Changes」セクションの見出し部分にカーソルを合わせると表示される「-」ボタンをクリックすることで、すべてのステージング済みファイルを一括で取り消せます。
新規作成したファイル（new file）だけを取り消す
新しく作成したファイルをgit addした場合、取り消し後の状態が少し異なります。理解しておくと混乱を避けられます。
新規ファイルの取り消し例：
# 新規ファイルを作成してaddした状況
$ git status
Changes to be committed:
new file: new-feature.js
# 新規ファイルのステージングを取り消す
$ git restore --staged new-feature.js
# 実行後の状況
$ git status
Untracked files:
(use "git add <file>..." to include in what will be committed)
new-feature.js
重要なポイント
- 既存ファイルの変更の場合：取り消し後は「Changes not staged for commit」になる
- 新規ファイルの場合：取り消し後は「Untracked files」になる
- どちらもファイル自体は削除されません
新規ファイルを完全に削除したい場合：
# ファイルを完全に削除する（注意：元に戻せません）
$ rm new-feature.js
# または、Gitから除外するだけ（ファイルは残す）
$ git restore --staged new-feature.js
$ echo "new-feature.js" >> .gitignore
直前のgit addだけを取り消す方法と「取り消しの取り消し」
作業中に「やっぱり今の取り消しは間違いだった」と気づくこともあります。そんな時の対処法も覚えておきましょう。
直前の操作だけを取り消す
# 段階的にファイルをaddしていた場合
$ git add file1.txt
$ git add file2.txt
$ git add file3.txt
# 最後のfile3.txtだけを取り消したい
$ git restore --staged file3.txt取り消しの取り消し（再度addする）
# ステージングを取り消した後
$ git restore --staged important-file.js
# やっぱり必要だった場合、再度addする
$ git add important-file.js
# 確認
$ git status
Changes to be committed:
modified: important-file.jsSourcetreeでの操作
Sourcetreeでは以下の操作で簡単に取り消しや再追加ができます：
- 取り消し: 「Staged files」から「Unstaged files」にドラッグ＆ドロップ
- 再追加: 「Unstaged files」から「Staged files」にドラッグ＆ドロップ
- 右クリックメニュー: 「Stage」や「Unstage」を選択
作業のコツ：
- こまめに
git statusで状況を確認する習慣をつける - 大きな変更をする前は
git stashでバックアップを取る - チーム開発では、取り消し操作も含めて作業手順を統一する
取り消し操作に慣れることで、Gitをより安心して使えるようになります。「間違えても大丈夫」という気持ちで、積極的に操作を覚えていきましょう。
コストパフォーマンスに優れた高性能なレンタルサーバー
【Hostinger】
git add取り消し時の注意点とベストプラクティス
git addの取り消し操作は比較的安全ですが、チーム開発や複雑なプロジェクトでは思わぬ影響を与えることがあります。ここでは、安全に作業を進めるための注意点と、開発チームで統一すべきルールについて解説します。
取り消し操作がpushや他ファイルに与える影響
ローカル環境での影響範囲
まず安心していただきたいのは、git addの取り消しはローカル環境にのみ影響し、既にリモートリポジトリにpushされたコミットには一切影響しないということです。
# この操作はローカル環境のみに影響
$ git restore --staged file.txt
# リモートリポジトリには全く影響しない
$ git status
$ git log # 既存のコミット履歴は変わらないステージングエリアと作業ディレクトリの関係
取り消し操作がどこに影響するかを理解することで、より安心して操作できます：
# 現在の状況を詳しく確認
$ git status --porcelain
M staged-file.txt # ステージング済み（Mが左側）
M unstaged-file.txt # 未ステージング（Mが右側）
MM both-changed.txt # 両方に変更あり
A new-staged.txt # 新規ファイル（ステージング済み）
?? untracked.txt # 追跡されていないファイル
# staged-file.txtの取り消し後
$ git restore --staged staged-file.txt
$ git status --porcelain
M staged-file.txt # ステージングから作業ディレクトリに移動
M unstaged-file.txt # 変化なし
MM both-changed.txt # 変化なし
?? new-staged.txt # 新規ファイルは「Untracked」になる
?? untracked.txt # 変化なし他のファイルへの影響
良いニュース：git addの取り消しは、他のファイルの状態に影響を与えません。
# 複数ファイルが混在している状況
$ git status
Changes to be committed:
modified: important.js
modified: config.txt
new file: test.js
Changes not staged for commit:
modified: style.css
# config.txtだけを取り消す
$ git restore --staged config.txt
# 他のファイルの状態は保持される
$ git status
Changes to be committed:
modified: important.js # そのまま
new file: test.js # そのまま
Changes not staged for commit:
modified: style.css # そのまま
modified: config.txt # ここに移動しただけ
git addとgit commit・git checkoutとの違いを整理
Gitの操作に慣れないうちは、似たようなコマンドで混乱することがあります。それぞれの役割を明確にしておきましょう。
コマンドの役割分担
| コマンド | 役割 | 影響範囲 | 危険度 |
|---|---|---|---|
git add | 作業ディレクトリ → ステージングエリア | ローカルのみ | ★☆☆ |
git restore --staged | ステージングエリア → 作業ディレクトリ | ローカルのみ | ★☆☆ |
git commit | ステージングエリア → ローカルリポジトリ | ローカルのみ | ★★☆ |
git push | ローカルリポジトリ → リモートリポジトリ | チーム全体 | ★★★ |
git checkout | ブランチ切り替えまたはファイル復元 | 状況による | ★★☆ |
混同しやすいコマンドとの違い
git restore --staged vs git restore（–stagedなし）
# ステージングを取り消す（ファイル内容は保持）
$ git restore --staged file.txt
# ファイルの変更自体を破棄する（危険！）
$ git restore file.txtgit reset の種類と使い分け
# ステージングのみリセット（推奨：安全）
$ git reset
$ git reset HEAD file.txt
# コミット自体を取り消す（注意が必要）
$ git reset --soft HEAD~1 # ステージングは保持
$ git reset --mixed HEAD~1 # ステージングをリセット
$ git reset --hard HEAD~1 # すべて破棄（危険！）取り返しのつかない操作を避けるために
安全な操作の順序：
- まず
git statusで状況確認 - 必要に応じて
git stashでバックアップ git restore --stagedで取り消し- 再度
git statusで結果確認
危険な操作（避けるべき）：
# これらの操作は慎重に！
$ git restore file.txt # 変更を破棄
$ git reset --hard # 全変更を破棄
$ git checkout HEAD -- file.txt # 変更を破棄
チーム開発でのミス防止と安全な運用ルール
チーム開発では、個人のミスが他のメンバーに影響することがあります。以下のルールを参考に、安全な開発環境を構築しましょう。
推奨する開発フロー
1. 作業前のルーティン
# 最新の状態を取得
$ git pull origin main
# 作業用ブランチを作成
$ git checkout -b feature/new-function
# 現在の状況を確認
$ git status2. 作業中のこまめな確認
# 変更内容を確認してからadd
$ git diff
$ git diff --staged # ステージング済みの差分確認
# 段階的にadd
$ git add specific-file.js
$ git status
# 間違いがあれば即座に修正
$ git restore --staged wrong-file.js3. コミット前の最終確認
# ステージング済みファイルの最終確認
$ git status
$ git diff --staged
# 問題なければコミット
$ git commit -m "Add new feature implementation"チーム運用のベストプラクティス
Git設定の統一
# エディタの設定（チーム共通）
$ git config --global core.editor "code --wait"
# 改行文字の設定（OS混在チーム向け）
$ git config --global core.autocrlf input # macOS/Linux
$ git config --global core.autocrlf true # Windows.gitignoreの整備
# プロジェクト固有の除外設定
echo "node_modules/" >> .gitignore
echo "*.log" >> .gitignore
echo ".env" >> .gitignore
echo "dist/" >> .gitignore
# 設定ファイル自体をコミット
$ git add .gitignore
$ git commit -m "Add gitignore for common files"コードレビューでのチェックポイント
- 不要なファイル（ログファイル、設定ファイルなど）がコミットに含まれていないか
- コミットメッセージが適切か
- 1つのコミットで変更量が適切か
トラブル対応のエスカレーションルール
レベル1: 個人で対応可能
git addの取り消し- ローカルでの作業ディレクトリの調整
- まだpushしていないコミットの修正
レベル2: チームリーダーに相談
- push済みコミットの修正が必要
- ブランチの統合で問題が発生
- 他メンバーの作業に影響する可能性
レベル3: プロジェクト全体への影響
- mainブランチへの誤った変更
- リモートリポジトリの履歴を変更する必要
- セキュリティ上問題のあるファイルをpushしてしまった
GUIツールでの安全な作業
VS Codeの活用
- Source Control拡張機能で視覚的に変更を確認
- ファイル単位での差分表示を活用
- ステージングとアンステージングをマウス操作で実行
Sourcetreeの活用
- ファイルツリーで変更箇所を一覧表示
- ドラッグ&ドロップでの直感的な操作
- コミット前のプレビュー機能を活用
これらのベストプラクティスを身につけることで、git addの取り消しだけでなく、Git全体を安全に使いこなせるようになります。「間違いを恐れずに、でも慎重に」を心がけて、チーム開発を成功させましょう。
よくある質問（FAQ）
-
git addを取り消してもファイルは消えませんか？ -
全く消えません。安心してください。
git restore --stagedやgit resetなどの取り消し操作は、あくまで「次のコミットに含める予定のファイル一覧」からの除外だけを行います。ファイルの内容や存在自体には一切影響しません。# 取り消し前 $ ls index.html style.css script.js $ git status Changes to be committed: modified: style.css # 取り消し実行 $ git restore --staged style.css # 取り消し後（ファイルは全て残っている） $ ls index.html style.css script.js $ git status Changes not staged for commit: modified: style.css # ここに移動しただけファイルが消える操作（参考：これらは別のコマンドです）
$ git restore style.css # 変更内容を破棄（危険） $ rm style.css # ファイル自体を削除（危険）
-
取り消しを取り消すことはできますか？
-
はい、簡単にできます。
git addの取り消しは完全に可逆的な操作です。間違って取り消した場合は、再度git addすれば元の状態に戻ります。# 誤って取り消してしまった場合 $ git restore --staged important-file.js # 再度addして元に戻す $ git add important-file.js # または複数ファイルを一括で戻す $ git add .この操作に制限や回数制限はありません。何度でも
git addと取り消しを繰り返せます。
-
新しく作成したファイル（new file）の取り消し後はどうなりますか？
-
「Untracked files」状態になりますが、ファイルは残ります。
新規ファイルと既存ファイルでは、取り消し後の状態が異なります：
# 新規ファイルをaddした場合 $ git status Changes to be committed: new file: new-component.js # 取り消し実行 $ git restore --staged new-component.js # 結果：「Untracked files」になる $ git status Untracked files: (use "git add <file>..." to include in what will be committed) new-component.js状態の違い：
- 既存ファイル: 取り消し後は「Changes not staged for commit」
- 新規ファイル: 取り消し後は「Untracked files」
どちらもファイル自体は保持されます。
-
間違って全部取り消してしまいました。一括で元に戻せますか？
-
はい、
git add .で一括復元できます。# 全部取り消してしまった場合 $ git reset # 全ファイルを一括で再度add $ git add . # または変更されたファイルのみ $ git add -uコマンドの使い分け：
git add .: すべてのファイル（新規ファイル含む）git add -u: 既に追跡されているファイルの変更のみgit add *.js: 特定の拡張子のファイルのみ
-
git commitした後でも取り消しできますか？ -
コミット後は異なる方法が必要ですが、可能です。
git addの取り消しはコミット前の操作です。コミット後の場合は以下の方法を使用します：# 直前のコミットを取り消してステージングに戻す $ git reset --soft HEAD~1 # 直前のコミットを取り消して作業ディレクトリに戻す $ git reset --mixed HEAD~1 # または単に $ git reset HEAD~1 # コミット内容を確認 $ git log --oneline -3注意： push済みの場合は、チームメンバーに影響する可能性があるため、慎重に検討してください。
-
.gitignoreに書いたファイルもgit addできてしまいます。なぜですか？ -
既に追跡されているファイルは
.gitignoreの影響を受けません。# 既に追跡されているファイルの場合 $ git rm --cached config.txt # 追跡を停止 $ echo "config.txt" >> .gitignore $ git add .gitignore $ git commit -m "Stop tracking config.txt" # 新規ファイルの場合（正常に無視される） $ echo "logs/" >> .gitignore $ touch logs/debug.log $ git status # logs/debug.logは表示されない
まとめ
この記事では、git addの取り消し方法について、基本操作から実践的な使い分け、そしてチーム開発での注意点まで幅広く解説してきました。Git初心者の方でも安心して操作できるよう、具体的なコマンド例とGUIツールでの操作方法も併せてご紹介しました。
最も大切なのは、git addの取り消し操作は完全に安全であるということです。ファイルの内容が失われることはありませんし、リモートリポジトリや他のチームメンバーに影響を与えることもありません。「間違えても大丈夫」という気持ちで、積極的に操作を覚えていただければと思います。
現在推奨されているgit restore --stagedコマンドを中心に、状況に応じてgit resetも使い分けることで、効率的な開発作業が可能になります。単一ファイルの取り消しから複数ファイルの一括操作まで、様々なシーンで活用してください。
新規作成したファイルは取り消し後に「Untracked files」状態になることや、既存ファイルとの挙動の違いも理解しておくと、より安心して操作できるでしょう。また、チーム開発では段階的な確認手順を習慣化することで、ミスを未然に防ぎつつ、万が一の場合も適切に対処できます。
Gitは最初は複雑に感じるかもしれませんが、基本的な操作から始めて徐々に覚えていけば、必ず使いこなせるようになります。この記事でご紹介した内容を実際の開発作業で試してみて、git addの取り消し操作をマスターしてください。
