Gitで削除したファイルを戻す｜未コミット・コミット済み・push済みの手順

Gitで管理していたファイルを消してしまったら、まず git status で削除の状態を確認します。未コミットならステージや最新コミットから、コミット済みなら削除前のコミットから戻せます。push済みでも、復元を新しいコミットとして追加できます。

ただし、Gitに記録していない編集まで戻るとは限りません。この記事では、必要な1ファイルだけを戻す手順を中心に説明します。add・commit・pushの基本はGitの基本的なコマンドで確認できます。

まず削除の状態を確認する

WindowsのPowerShellで、対象リポジトリの一番上のフォルダーを開きます。以下の memo.txt は、実際の相対パスに置き換えてください。例：docs/work memo.txt。

git --version
git status
git status --short

git restore にはGit 2.23以降が必要です。通常、短い表示の先頭2文字は左がステージ、右が作業ツリーの変更を表します。空白の位置にも意味があります。

 D memo.txt
D  memo.txt
MD memo.txt

上から「未ステージの削除」「ステージ済みの削除」「編集をステージした後、手元で削除」の例です。状態表示の公式説明

状態	戻し方
`D` または `MD`	ステージから手元のファイルを戻す
`D`	最新コミットからステージと手元のファイルを戻す
削除をコミット済み	ファイルが残る過去の版を取り出し、新しくコミットする
削除コミットをpush済み	同じ方法で復元し、新しいコミットを共有する

ステージ（インデックス）は、次のコミットに入れる内容の置き場です。作業ツリーは手元のファイル、HEAD は通常、今いるブランチの最新コミットを指します。

statusに出ないだけでは、コミット済み・push済みとは判断できません。 Gitで管理していなかったファイルや、別のブランチを見ている可能性もあります。後述の履歴を確認しましょう。

復元する前に

残したい未コミットの内容は、リポジトリの外へコピーするなどして保存します。同名のファイルを作り直している場合も、復元で上書きされるので退避してください。ステージと手元の内容が違うこともあるため、git diff と git diff --staged の両方を確認します。競合やmerge・rebaseの途中なら、この手順を進めず、進行中の操作を先に確認してください。

以下は、一度コミットされた通常のファイルを対象にします。コマンドは対象パスを引用符で囲み、-- でオプションとの境界を示しています。全体を戻す git restore . や git reset --hard は使いません。

未コミットの削除を戻す

削除が未ステージ：ステージから戻す

D memo.txt または MD memo.txt なら、次を実行します。

git restore -- "memo.txt"
git status --short

エディタでファイルを開き、中身を確認します。復元元は現在のステージです。

D だった場合：ほかに変更がなければ、対象ファイルの表示は消えます
MD だった場合：add済みの編集が戻り、M が残ります。その編集は引き続きステージされています

削除前の編集をaddしていなければ、その編集分は戻りません。別ファイルの変更がそのまま残っていることも、status全体で確認します。

削除がステージ済み：最新コミットから2か所を戻す

git rm を使った場合や、削除後にaddした場合は D memo.txt になります。HEAD にある版へ戻すには、復元元と復元先を指定します。

git restore --source=HEAD --staged --worktree -- "memo.txt"
git status --short

--staged はステージ、--worktree は手元のファイルの指定です。両方が HEAD の内容になり、対象にほかの変更がなければstatusから消えます。ファイルの中身も確認してください。restoreの公式説明

git restore --staged -- "memo.txt" だけでは、手元のファイルは戻りません。また、上の手順で戻るのは最新コミットの版です。以前addした編集があっても、その後に削除をステージすると、現在のステージにはその編集が残っていません。

コミット済みなら、過去の版から1ファイルだけ戻す

共有ブランチへ直接コミットしない運用なら、復元を始める前に、プロジェクトのルールに沿って作業ブランチを用意します。

1. 削除前の内容を確かめる

対象ファイルを削除したコミットを探します。--diff-filter=D は削除に絞る指定です。logの公式説明

git log --oneline --diff-filter=D -- "memo.txt"

以下の a1b2c3d は例です。自分の結果に出た削除コミットのIDに、すべて置き換えてください。 候補が複数あれば、戻したい削除を選びます。

git show --stat a1b2c3d
git show "a1b2c3d^:memo.txt"

1行目で変更したファイル、2行目で削除直前の内容を確認します。^ は最初の親コミットを表します。ここでは親が1つの通常のコミットを想定しています。コミットとパスの指定方法

内容が表示されない場合は、まだ復元しません。名前変更・移動、マージ、別ブランチ、履歴を一部だけ取得したcloneでは、単純に ^ を付けても目的の版が見つからないことがあります。ファイルが存在したコミットと当時のパスを確認してください。

2. 内容を取り出し、復元だけをコミットする

表示された版が目的の内容なら、次で取り出します。

git restore --source="a1b2c3d^" -- "memo.txt"
git status --short

指定した版を手元に置く操作で、ステージやコミット履歴は変わりません。現在のコミットとステージにファイルがなければ、通常は ?? memo.txt（未追跡）になります。

エディタで内容を確認してから、対象だけをaddします。

git add -- "memo.txt"
git diff --staged

ここで、コミットに入る差分全体を確認します。 次の git commit は、今回addしたファイルだけでなく、すでにステージにある別の変更も記録します。関係のない変更が混ざっていたら、そのまま進まず、別コミットへ保存するなどして分けてください。commitの公式説明

復元分だけがステージされていれば、記録します。

git commit -m "Restore memo.txt"
git show --stat HEAD
git status --short

削除コミットは残り、復元コミットが増えます。削除と同じコミットに含まれていた別ファイルの修正や、別ファイルの未コミット編集は、この復元では取り消されません。

コミット全体を取り消す場合だけrevertを使う

1ファイルを戻したいなら、前節のrestoreを選びます。 git revert は、指定したコミットに含まれる変更全体を打ち消す、新しいコミットを作ります。削除と一緒に行った別ファイルの編集も対象です。

revertを選ぶ場合は、前節の復元コミットを作る代わりに、次の手順へ進みます。残したい未コミットの作業を保存・整理し、statusがcleanであることを確認します。

git status
git show a1b2c3d

a1b2c3d は取り消したいコミットのIDです。表示された変更をすべて取り消してよい場合だけ実行します。

git revert --no-edit a1b2c3d

--no-edit はコミットメッセージの編集画面を開かない指定です。成功したら、戻ったファイルの中身、git show --stat HEAD、git status を確認します。後続のコミットを丸ごと消す操作ではありません。revertの公式説明

競合した場合は完了していません。解消方法が分からず今回のrevertを中止するなら、次で開始前へ戻せます。

git revert --abort

マージコミットのrevertには別の判断が必要なので、ここでは扱いません。

push済みでも、新しいコミットで戻せる

削除をpushしていても、restoreで作った復元コミットやrevertのコミットを通常の方法で共有できます。共有済みの履歴を書き換える必要はありません。

push済みかどうかはstatusだけでは分かりません。必要ならGitHubやGiteaの対象ブランチで削除コミットを確認します。共有済みか不明な場合も、履歴を残すこの方法を選べます。

いつものpush先が設定済みなら、まず現在のブランチと送信予定を確認します。

git branch --show-current
git remote -v
git push --dry-run

--dry-run は送信先を実際には更新せず、予定を表示します。意図したリポジトリとブランチへの送信になっていることを確認してから進みます。送信先が不明、未設定、またはエラーになった場合は、そのまま実行しません。pushの公式説明

git push

拒否されてもforce pushはせず、リモート側の更新や保護ルールを確認します。成功後はGitHubやGiteaの送信先ブランチで、復元コミットとファイル内容を確認してください。PRが必要な運用では、作業ブランチへのpushの後にPRを作成します。pushだけで共有ブランチへ反映されるわけではありません。

Gitに記録していない内容は別の保存先も確認する

Gitから戻せるのは、記録が残っている内容です。

一度もadd・commit・stashなどで記録していない新規ファイルや編集は、この手順では戻りません
編集をaddした後、削除をまだaddしていなければ、現在のステージから戻せます（MD の例）
過去にaddしただけで現在のステージにも残っていない内容は、この手順での復元を保証できません

Windowsのごみ箱、エディタのローカル履歴、バックアップも確認先になります。削除方法や設定によって残り方が違うので、復旧先を探している間は不要な削除やクリーンアップを避けましょう。

最後は、ファイルの中身、status、作成したコミット、共有先を確認します。「コマンドが成功した」だけで終わらせず、必要な版が戻ったことを確かめて完了です。

確認環境

代表的なGit操作は、Debian GNU/Linux 13・Git 2.52.0の一時リポジトリで確認しています。push先にはローカルのbareリポジトリを使用しました。コマンド例はPowerShell向けの表記ですが、Windows／PowerShellでの実行は未確認です。

本文中のGit公式資料は2026年10月12日に確認しました。