章 ▾ 第2版

2.4 Gitの基本 - 取り消し

取り消し

どの段階においても、何かを取り消したいと思うことがあるでしょう。ここでは、行った変更を取り消すためのいくつかの基本的なツールについて説明します。これらの取り消しの中には、常に元に戻せるわけではないものもあるので、注意が必要です。これは、間違ったやり方をすると作業を失う可能性があるGitの数少ない領域の一つです。

よくある取り消しの一つは、早すぎるコミットをしてしまい、ファイルをいくつか追加し忘れたり、コミットメッセージを間違ってしまったりした場合です。そのコミットをやり直したい場合は、忘れずに済ませた追加の変更を加え、それらをステージし、--amend オプションを使用して再度コミットします。

$ git commit --amend

このコマンドは、ステージングエリアの内容をコミットに利用します。前回のコミットから変更がない場合（たとえば、前回のコミットの直後にこのコマンドを実行した場合）、スナップショットはまったく同じになり、変更されるのはコミットメッセージだけです。

同じコミットメッセージエディタが起動しますが、そこにはすでに前回のコミットのメッセージが含まれています。メッセージはいつもと同じように編集できますが、それは前回のコミットを上書きします。

例として、コミットした後、このコミットに追加したかったファイルの変更をステージし忘れたことに気づいた場合、次のようにすることができます。

$ git commit -m 'Initial commit'
$ git add forgotten_file
$ git commit --amend

最終的には単一のコミットになります — 2回目のコミットが最初のコミットの結果を置き換えます。

注意

最後のコミットを修正する場合、それは単に修正するのではなく、古いコミットを排除し、その場所に新しい、より良いコミットを完全に「置き換える」ことだと理解することが重要です。事実上、以前のコミットはなかったことになり、リポジトリの履歴には表示されません。

コミットを修正する明らかな価値は、「しまった、ファイルをaddし忘れた」とか「くそっ、前回のコミットのタイプミスを修正」といった形式のコミットメッセージでリポジトリの履歴を散らかさずに、最後のコミットに軽微な改善を加えることです。
注意

ローカルにのみ存在し、まだどこにもプッシュされていないコミットのみを修正してください。以前にプッシュされたコミットを修正し、ブランチを強制プッシュすると、共同作業者に問題を引き起こします。これを実行したときに何が起こるか、そして受信側になった場合にどのように回復するかについては、リベースの危険性を参照してください。

ステージングされたファイルのアンステージング

次の2つのセクションでは、ステージングエリアとワーキングディレクトリの変更を操作する方法を示します。便利なのは、これらの2つのエリアの状態を決定するために使用するコマンドが、それらの変更を元に戻す方法も教えてくれる点です。たとえば、2つのファイルを変更し、それらを2つの別々の変更としてコミットしたいが、誤ってgit add *と入力して両方をステージしてしまったとします。そのうちの1つをアンステージするにはどうすればよいでしょうか？git status コマンドが教えてくれます。

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

「Changes to be committed」のテキストのすぐ下に、アンステージするにはgit reset HEAD <file>…​を使うように書かれています。では、そのアドバイスに従ってCONTRIBUTING.mdファイルをアンステージしましょう。

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M	CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

このコマンドは少し奇妙ですが、機能します。CONTRIBUTING.mdファイルは変更されていますが、再びアンステージされました。

注意

確かにgit resetは危険なコマンドであり、特に--hardフラグを指定した場合はそうです。しかし、上記で説明したシナリオでは、ワーキングディレクトリ内のファイルは変更されないため、比較的安全です。

今のところ、git resetコマンドについて知っておくべきことは、この魔法のような呼び出し方だけです。resetが何をするのか、そして本当に興味深いことを行うためにそれをマスターする方法については、Resetの謎を解くでさらに詳しく説明します。

変更されたファイルを元に戻す

もし、CONTRIBUTING.mdファイルへの変更を保持したくないと気づいたらどうしますか？簡単に元に戻すにはどうすればよいでしょう—最後にコミットした時点（または最初にクローンした時点、あるいはどのようにしてワーキングディレクトリに置いたか）の状態に戻すには？幸いなことに、git statusはその方法も教えてくれます。最後の出力例では、アンステージングエリアは次のようになっています。

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

行った変更を破棄する方法を非常に明示的に示しています。指示通りにやってみましょう。

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

変更が元に戻されたことがわかります。

重要

git checkout -- <file>が危険なコマンドであることを理解することが重要です。そのファイルに行ったローカルでの変更はすべて失われます — Gitはそのファイルを、最後にステージングまたはコミットされたバージョンで置き換えるだけです。これらの保存されていないローカル変更が絶対に不要だと分かっている場合を除き、このコマンドは決して使用しないでください。

そのファイルに行った変更を保持したいが、今のところそれを邪魔しないようにする必要がある場合は、Gitのブランチでスタッシュとブランチについて説明します。これらは通常、より良い方法です。

Gitで「コミット」されたものは、ほぼ常に回復可能であることを覚えておいてください。削除されたブランチにあったコミットや、--amendコミットで上書きされたコミットでさえ回復できます（データ回復についてはデータ回復を参照してください）。しかし、コミットされなかったものは、二度と見ることができない可能性が高いです。

git restoreで取り消す

Gitバージョン2.23.0で新しいコマンド：git restoreが導入されました。これは基本的に、これまで説明したgit resetの代替となるものです。Gitバージョン2.23.0以降、多くの取り消し操作でgit resetの代わりにgit restoreが使用されます。

では、手順をやり直し、git resetの代わりにgit restoreを使って元に戻しましょう。

git restoreでステージングされたファイルをアンステージングする

次の2つのセクションでは、git restoreを使ってステージングエリアとワーキングディレクトリの変更を操作する方法を示します。便利なのは、これらの2つのエリアの状態を決定するために使用するコマンドが、それらの変更を元に戻す方法も教えてくれる点です。たとえば、2つのファイルを変更し、それらを2つの別々の変更としてコミットしたいが、誤ってgit add *と入力して両方をステージしてしまったとします。そのうちの1つをアンステージするにはどうすればよいでしょうか？git status コマンドが教えてくれます。

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   CONTRIBUTING.md
	renamed:    README.md -> README

「Changes to be committed」のテキストのすぐ下に、アンステージするにはgit restore --staged <file>…​を使うように書かれています。では、そのアドバイスに従ってCONTRIBUTING.mdファイルをアンステージしましょう。

$ git restore --staged CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    README.md -> README

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:   CONTRIBUTING.md

CONTRIBUTING.mdファイルは変更されていますが、再びアンステージされました。

git restoreで変更されたファイルを元に戻す

もし、CONTRIBUTING.mdファイルへの変更を保持したくないと気づいたらどうしますか？簡単に元に戻すにはどうすればよいでしょう—最後にコミットした時点（または最初にクローンした時点、あるいはどのようにしてワーキングディレクトリに置いたか）の状態に戻すには？幸いなことに、git statusはその方法も教えてくれます。最後の出力例では、アンステージングエリアは次のようになっています。

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:   CONTRIBUTING.md

行った変更を破棄する方法を非常に明示的に示しています。指示通りにやってみましょう。

$ git restore CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    README.md -> README
重要

git restore <file>が危険なコマンドであることを理解することが重要です。そのファイルに行ったローカルでの変更はすべて失われます — Gitはそのファイルを、最後にステージングまたはコミットされたバージョンで置き換えるだけです。これらの保存されていないローカル変更が絶対に不要だと分かっている場合を除き、このコマンドは決して使用しないでください。
scroll-to-top