git restoreの使い方！ファイルの変更破棄・git addの取り消し方法

Gitユーザにお勧めの本 ↗

初心者向け

いちばんやさしいGit&GitHubの教本 第3版 人気講師が教えるバージョン管理＆共有入門 「いちばんやさしい教本」シリーズ

難易度

実用性

読みやすさ

こんな人におすすめ： Gitをこれから使い始める人、挫折した経験がある人

とにかく挫折しない丁寧な解説。チーム開発での基本的な流れを確実にマスターできます。

Amazon 🔴 楽天

改訂2版 わかばちゃんと学ぶ Git使い方入門

難易度

実用性

読みやすさ

こんな人におすすめ： マンガで楽しくGitを学びたい人

漫画形式で視覚的にイメージしやすい。Git特有の難しい用語も、物語を通して自然に理解できます。

Amazon 🔴 楽天

独習Git

難易度

実用性

読みやすさ

こんな人におすすめ： Gitの内部構造や高度な機能を学びたい人

コマンドの裏側で何が起きているかを丁寧に解説。プロとしてGitを使いこなすためのバイブルです。

Amazon 🔴 楽天

📚 ITエンジニア向けおすすめ技術書・関連書籍まとめはこちら

「作業中のファイルをうっかり書き換えてしまったけれど、変更前の状態に戻すにはどうすればいいんだろう…」 「git add したファイルを元の状態に戻したいけれど、どのコマンドを使えば安全なのか迷ってしまう」

GitGit [ギット]ソースコードの変更履歴を管理する分散型バージョン管理システムを使って開発を進める中で、このようなファイルの変更取り消しに悩んだ経験はないでしょうか。誤ったコマンドを使ってしまうと、せっかく書いたコードが消えてしまうのではないかと不安になりますよね。

この記事では、Git 2.23で導入された git restore コマンドの使い方を徹底解説します。作業ディレクトリの変更破棄から、ステージングの解除、特定のコミットからのファイル復元まで、実務で役立つ意図した操作を安全に行う方法がわかるようになります。

git restoreとは？git checkoutとの違いを解説

git restoreの基本的な役割とメリット

Gitでファイルの状態を理解するうえでは、「HEAD（現在のHEADが指しているコミット）」「INDEXindex [インデックス]検索を高速化するためのデータ構造（ステージングエリア）」「WORKING TREE（作業ツリー）」の3つを意識すると分かりやすくなります。git restore は、作業ツリーやインデックスのファイルを、指定した復元元の内容に合わせて復元するためのコマンドです。

1
       HEAD
2
        │
3
        │ git restore --staged <file>
4
        ↓
5
       INDEX
6
        │
7
        │ git restore <file>
8
        ↓
9
   WORKING TREE

過去のコミットなどを復元元（--source）として指定することも可能です。

1
 指定したコミット
2
        │
3
        │ git restore --source=<commit> <file>
4
        ↓
5
   WORKING TREE

git restore は、Gitの作業ディレクトリ（ワーキングツリー）やステージングエリア（インデックス）にあるファイルの変更を取り消すために設計されたコマンドです。

従来のGitでは、ファイルの変更破棄やブランチの切り替えなど、多くの役割が git checkout や git reset という一つのコマンドに集中していました。そのため、「今どの状態の操作をしているのか」がわかりにくく、誤操作によって意図しない変更を失うリスクがありました。

git restore は「ファイルの復元（復旧）」に特化しているため、コマンドの意図が明確になり、ファイルの復元操作を意図して実行できるというメリットがあります。Git 2.23では、従来の checkout の役割を、ブランチ操作の switch とファイル復元の restore に分ける形で導入されました。

git checkoutやgit resetとの使い分け

Git 2.23で git checkout からファイル復元の役割が分離され、現在の各コマンドの役割は以下の表のようになっています。

このように、ファイルの復元やステージング解除には git restore を使用し、ブランチの操作には git switch を使用するのが近年のGitにおける標準的なプラクティスとなっています。

作業ディレクトリの変更を取り消す方法（ファイルの破棄）

ワーキングツリーの変更を直前の状態に戻す手順

作業ツリーの変更を破棄して、ステージングエリア（index）の状態に戻したい場合は、オプションなしで git restore を実行します。

例えば、app.js というファイルに誤った変更を加えた場合、以下のコマンドを実行します。

1
git restore app.js

git restore app.js は、デフォルトではステージングエリア（インデックス）の内容を使って、app.js の作業ディレクトリ（ワーキングツリー）を復元します。ステージングされていない作業ツリーの変更は失われるため、実行前には本当に不要な変更であるかを確認してください。

特定のファイルだけを元に戻すコマンド例

複数のファイルを変更した場合、特定のファイルやディレクトリだけを指定して復元することができます。

1
# 単一のファイルを元に戻す
2
git restore index.html
3

4
# 複数ファイルを指定して元に戻す
5
git restore src/styles.css src/main.js
6

7
# カレントディレクトリ配下の作業ツリーの変更を、ステージングエリア（index）の状態に戻す
8
git restore .

コマンドの実行時にファイルパスを指定することで、対象とするファイルを限定して復元できます。

ステージング（add済みの状態）を取り消す方法

—stagedオプションを使ったステージング解除

git add を実行してステージングエリア（インデックス）に追加したものの、コミットする前に「やっぱりこのファイルは一度ステージから外したい」という場合があります。このときは --staged オプションを使用します。

1
git restore --staged app.js

このコマンドを実行すると、ステージングエリア（インデックス）をHEADの状態に戻します。作業ツリーの変更はそのまま残ります。

実行した際の出力例は以下のようになります。

1
$ git status
2
On branch main
3
Changes to be committed:
4
  (use "git restore --staged <file>..." to unstage)
5
        modified:   app.js
6

7
$ git restore --staged app.js
8

9
$ git status
10
On branch main
11
Changes not staged for commit:
12
  (use "git add <file>..." to update what will be to commit)
13
  (use "git restore <file>..." to discard changes in working directory)
14
        modified:   app.js

git restore —stagedとgit resetの違い

従来、ステージングの解除には git reset HEAD <file> が一般的に使われていました。

git restore --staged <file> は、指定したファイルのインデックスをHEADの状態に戻す操作で、ファイル単位のステージング解除という点では git reset HEAD <file> と同等の結果になります。git restore --staged <file> は、ステージング解除という操作の意図をコマンド名から把握しやすい点がメリットです。

また、ステージングを解除した後に続けて作業ディレクトリの変更も完全に破棄したい場合は、以下のように2段階で実行します。

1
# ステージングを解除
2
git restore --staged app.js
3

4
# 作業ディレクトリの変更も破棄
5
git restore app.js

特定コミットの状態までファイルを復元する方法

—sourceオプションで過去のバージョンに戻す

git restore は、直前のコミットだけでなく、過去の特定のコミットID（ハッシュ）やブランチを指定して、その時点のファイルの状態を復元することができます。これには --source オプションを使用します。

例えば、特定のファイルだけを2つ前のコミットの状態に戻したい場合は、以下のように実行します。

1
git restore --source=HEAD~2 src/config.json

コミットハッシュを指定する場合の構文は以下の通りです。

1
git restore --source=a1b2c3d src/config.json

このコマンドを実行すると、指定したコミット時点の src/config.json が現在の作業ディレクトリに上書きされます。特定の機能だけを過去のバージョンに戻して検証したい場面などに役立ちます。なお、この操作によって新しいコミットが自動的に作成されるわけではありません。

実務でよくあるトラブルと注意点

変更内容が完全に消えるリスクへの対策

git restore で破棄した未コミットの変更は、通常のGit操作では元に戻せなくなるため、実行前に内容を確認してください。誤って実行してコードを失うトラブルを防ぐため、以下の対策を意識しておくと安全です。

1. git diff で変更内容を事前に確認する
   復元コマンドを実行する前に、本当に捨てても問題ない変更かを確認します。作業ツリーの変更は git diff、ステージング済みの変更は git diff --cached で確認できます。

   1
   # まだaddしていない変更（作業ツリーとインデックスの差分）
   2
   git diff app.js
   3
   
   4
   # git add済みの変更（インデックスとHEADの差分）
   5
   git diff --cached app.js

2. 作業を一時退避させる git stash の活用
   「変更をいったん取り消したいけれど、後でやっぱり見返すかもしれない」という場合は、変更を完全に破棄するのではなく、git stash を使って一時退避させるのが安全です。未追跡ファイルもstashに含めたい場合は -u オプションを付けます。

   1
   # 現在の変更を退避（未追跡ファイルも含める場合は git stash -u）
   2
   git stash
   3
   
   4
   # 退避した変更の一覧確認
   5
   git stash list
   6
   
   7
   # 必要に応じて退避した変更を復元
   8
   git stash pop

まとめ：git restoreで安全にファイル操作を行おう

本記事では、Gitの変更を取り消すためのモダンなコマンド git restore について解説しました。

記事のポイントを以下にまとめます。

• git restore は、作業ツリーやステージングエリアのファイルを復元するためのコマンドである。
• オプションなしで実行すると、作業ディレクトリの変更が破棄され、デフォルトではステージングエリア（インデックス）の状態に戻る。
• --staged オプションを使用すると、作業ツリーの変更を残したまま、ステージングを解除できる。
• --source オプションを使用することで、過去の特定のコミット時点からファイルを復元できる。
• 誤って必要な変更を消去しないよう、実行前には git diff や git stash を活用する。

git switch や git restore によって、ブランチ操作とファイル復元操作をコマンドとして分けて扱えるようになりました。操作の目的を意識しながらコマンドを使い分けることで、意図しない操作を避けやすくなります。日々の開発フローに git restore を取り入れ、より効率的なバージョン管理を行いましょう。

おすすめ この記事に関連する技術本

改訂2版 わかばちゃんと学ぶ Git使い方入門

Amazon 🔴 楽天

この記事を書いた人

Z (ITナレッジライフ)

現役のITエンジニア。Linux、プログラミング、IT用語など、日々の業務で得た「痒いところに手が届く」技術情報を発信しています。

プロフィールと編集ポリシーを見る →