変更を取り消す（restore）

30 分いじって、全部いらなかった

試しに書き換えてみたが、やはり要らなかった。この「書く前に戻したい」は毎日起きます。取り消しキーを連打しても、途中で保存していると戻りきりません。

最後にコミットした状態が手元にあるので、そこから書き戻せます。

$ git status
On branch main
Changes not staged for commit:
  (use "git restore <file>..." to discard changes in working directory)
	modified:   src/app.js

$ git restore src/app.js
$ git status
On branch main
nothing to commit, working tree clean

git status の案内文に、打つべきコマンドがそのまま書かれています。git restore は、指定したファイルを最後のコミットの中身で上書きします。フォルダ以下をまとめて戻すなら git restore . です。

この回で扱うのは、まだコミットしていない変更の捨て方だけです。コミットまで済ませたものは git restore では動きません。そちらは git reset の担当です。

解説

git restore で消した編集は、二度と取り戻せません。 コミットもステージもしていない中身は Git のどこにも保存されていないので、あとから探す方法がありません。捨てる決心がつかないなら、git stash で棚に上げておくほうが安全です。

add を取り消すだけなら、中身は消えない

もう 1 つ、よく似ているのに結果が正反対の操作があります。コミットするつもりで git add したが、今回はそのファイルを含めたくない、というときです。

$ git restore --staged config/secret.json

--staged が付くと、動くのは「次のコミットに含める」という印だけです。書いた中身には一切触りません。だから何度打っても安全です。

8 文字の違いで、消えるものが変わります。ステージという印だけを動かす安全な操作が --staged あり、ファイルの中身を書き換える危険な操作が --staged なし。この対応で覚えてください。

消える中身を、先に目で見る

いちばん多い事故は、git add を取り消したかっただけなのに --staged を書き落として、1 時間かけて書いたコードを消してしまうことです。このとき Git は警告も確認も出しません。静かに終わります。

防ぎ方は 2 つあります。

1 つは、git status の案内文と、自分が打とうとしているコマンドが一致しているか、指差しで確かめることです。ステージにあるものには --staged を付けろ、と毎回書いてあります。

もう 1 つは、消える中身をそのまま表示してから決めることです。

$ git diff src/app.js

ここに出る差分が、そっくりそのまま消える内容です。読んで「これは捨ててよい」と判断してから打てば、事故は起きません。

なお、Git で戻せなくても、そのファイルを開いたままのエディタなら取り消し履歴が残っていることがあります。消してしまったと気づいたら、まずエディタの取り消しを試してください。

古い記事では、同じ操作に git checkout -- ファイル名 が使われています。動きは git restore と同じなので、見かけたら読み替えて構いません。