【Git】変更の取り消しを初心者向けにわかりやすく解説
はじめに
皆さんは、Gitでファイルを編集したあとに「この変更をなかったことにしたい」と思ったことはないでしょうか。
たとえばテスト用のコードを追加してからコミットしてしまったり、不要なファイルをステージに入れてしまったりすることがあります。
こうした状況で役立つのがGitの変更取り消しテクニックです。
Gitを使えば、コミットの履歴はもちろん、ワークツリーやステージングの状態まで、さまざまなレベルで変更を取り消せます。
ただし、使い方を間違えてしまうと、大切なコードを失うリスクもあります。
そのため、正しいコマンドや安全な手順を理解し、慎重に実行する必要があるのです。
ここでは、Gitを初めて触れる方でもわかりやすいように、代表的な変更取り消しの方法を手順とともに紹介します。
ぜひ実務での作業や個人の開発にお役立てください。
この記事を読むとわかること
- Gitでの変更取り消しの仕組みと基本的な考え方
- ワークツリーやステージングエリアでの変更を取り消す方法
- コミット後の変更を取り消す代表的な手順
- 実務シーンで役立つ注意点とトラブル回避のポイント
Gitの変更取り消しとは何か
Gitの変更取り消しとは、その名の通り「作業中の変更やコミットをなかったことにする」操作を指します。
しかし「なかったことにする」と言っても、実際にはGitの履歴を遡って操作する方法がいくつか存在します。
具体的には、以下のようなレベルで変更を取り消せます。
- ワークツリーの変更を取り消す
- ステージングエリアの変更（ステージに上げたファイル）を取り消す
- コミット後の変更を取り消す
それぞれのレベルによって使用するコマンドが異なります。
誤ったコマンドを使うと履歴自体を改変してしまったり、最新の状態が失われたりすることがあるので、注意しましょう。
実務でのイメージ
たとえば、新機能を実装しているときに不要なテストコードを一時的にコメントアウトしていたとします。
それをコミット前に元に戻したい場合や、うっかり余計なファイルをステージに上げてしまい、後で除外したい場合などが考えられます。
また、チーム開発では、間違えて誤った内容をコミットしてしまうこともあります。
そういったケースで、履歴を上書きするのではなく、新たなコミットを作成して「取り消しを記録する」方法もよく使われています。
ワークツリーの変更を取り消す方法
まずは最も基本となる「ワークツリーの変更取り消し」について見てみましょう。
ワークツリーとは、いま実際に手元で編集しているファイル群のことです。
まだステージには上げておらず、コミットもしていない状態の変更を戻すときに便利です。
git restore コマンドを使う
git restore はワークツリーやステージングエリアの変更を簡単に取り消すために用いられるコマンドです。
Gitのバージョンによっては git checkout で同様の操作をしていたケースもありますが、現在では git restore の方が明確な命令として推奨されています。
ワークツリーの変更だけを取り消す例
# 特定のファイルの変更を取り消す git restore path/to/file # 全ての変更を取り消す git restore .
これらはワークツリーに対する操作なので、まだステージングエリアに追加していないファイルが対象です。
「直前のコミットから変更があった部分を、元の状態に戻す」という動きになります。
実務で気をつけたいポイント
多くの場合、「ワークツリーのコードをまだコミットしたくないけど、元に戻したい」と感じるシーンは限定的です。
ただし、不要なファイルを誤って編集してしまった場合や、うまく動かないコードを丸ごと元に戻したいケースには非常に役立ちます。
一方で、ワークツリーの変更を取り消すと、その変更は後から復元できません。
コミット前の変更は履歴として残らないため、取り消すと取り返しがつかないので注意しましょう。
ステージングエリアの変更を取り消す方法
ワークツリーで変更したファイルを git add するとステージングエリアに移動します。
そして、その状態で git commit すると履歴にコミットされる仕組みです。
ステージングエリアに上げてしまった変更を「やっぱり取り消したい」という場合も多いでしょう。
たとえば「実際にはコミットしなくていい細かい変更を含めてしまった」といったケースがよくあります。
git restore --staged オプションを使う
ステージングエリアに移動した変更を取り消して、再びワークツリーの変更に戻すには --staged オプションを使います。
# ステージングエリアから変更を外す（ワークツリーには変更を残す） git restore --staged path/to/file # 全てのファイルをステージから外す git restore --staged .
これにより、コミット前に「もう少しコードを追加しよう」と考えた場合や、「一部のファイルだけ先にコミットしたい」という場合の調整をスムーズに行えます。
実務で気をつけたいポイント
ステージングエリアから外しただけでは、ワークツリーの変更自体はそのまま残ります。
つまり、「変更を削除する」のではなく「コミット対象から外す」操作になります。
もし変更自体も消してしまいたい場合は、ステージから外したあとで前述の git restore を使ってワークツリーの変更を取り消すなど、段階を踏む必要があります。
コミット後の変更を取り消す代表的な方法
ここからは、コミット後の変更を取り消す操作を見ていきましょう。
コミットは履歴として記録されるため、変更を「上書き」するのか、それとも「新たな取り消しコミットを作る」のかによって、使うコマンドや操作が異なります。
git revert で「取り消し用のコミット」を作る
git revert は「過去のコミットを取り消すためのコミット」を新たに作成します。
履歴を上書きせず、あくまでも「取り消しという事実」自体を履歴に残すため、チーム開発でよく使われる安全な方法です。
使い方の例
# 直前のコミットを取り消す git revert HEAD # 過去の特定のコミットを取り消す git revert <コミットハッシュ>
実務での例としては、誤ったコミットがすでにリモートリポジトリにプッシュされている場合、git revert を使うことが多いです。
なぜなら、git revert は過去の履歴を改変しないので、他の開発者の作業と衝突しにくいからです。
git reset で履歴を巻き戻す
git reset は「履歴そのものを巻き戻す」操作です。
コミット単位で履歴を消し去り、HEAD（最新のコミット）を指定した場所に戻すため、強力な変更取り消し方法として知られています。
reset の3つのモード
Gitでは、リセット先のオプションによって動きが変わります。
よく使われる3種類を簡単にまとめると次のようになります。
- --soft : コミットを取り消すが、ワークツリーとステージングの変更はそのまま
- --mixed : コミットを取り消して、変更はワークツリーに戻す（ステージングは空になる）
- --hard : コミットを取り消し、変更自体もすべて破棄
具体例
# 1つ前のコミットに戻す（--mixed がデフォルト） git reset HEAD^ # 変更ファイルも含めて巻き戻したい場合（危険） git reset --hard HEAD^
git reset --hard は履歴も変更内容もなかったことにするため、後でコードを取り戻せません。
誤って使うと作業内容がすべて消える恐れがあるので、十分気をつけてください。
チーム開発での注意
リモートにプッシュ済みのコミットを git reset や --force で上書きしてしまうと、他のメンバーの履歴と衝突する可能性が高まります。
こうした場合には git revert などで対応するのが一般的です。
特に共同作業中は、リモートリポジトリにプッシュ済みのコミットに対して安易に履歴書き換えを行うと、混乱が起きやすくなります。 必ずチームメンバーとコミュニケーションをとり、必要に応じてrevertを使うことを検討しましょう。
git stash で作業を一時退避させる
本格的な「変更取り消し」ではありませんが、変更を一時的に隠す（退避させる）ための方法としてgit stash があります。
何らかの理由で作業状態をいったん片付けたいが、あとで再開したい場合に便利です。
stash のメリット
- コミットせずに「途中の作業状態」を保存しておける
- 作業中のコードが邪魔で別のブランチ作業がやりにくいときなどに重宝する
stash の利用例
# 今の変更をstashに退避 git stash push -m "一時退避" # stashの一覧を確認 git stash list # stashを適用（最新のstashを反映） git stash apply # いらなくなったstashを削除 git stash drop
stashを使うことで、ワークツリーやステージングエリアの状態を一時的に保存しておき、必要なときに取り出せるようになります。
もし「途中のコードが不要だった」という場合は、stashした後に削除してしまえば結果的に変更取り消しに近い操作となるでしょう。
実務でありがちなシーンと対処例
ここからは、具体的なシーンを想定しながら、変更取り消しがどのように使われるか整理してみましょう。
初心者の方でもイメージしやすいように、よくある状況をいくつか挙げます。
まだコミットしていない単純な修正を取り消したい
たとえば、誤って不要なコードを入力してしまったけれど、コミット前に「いらない」と気づくシーンです。
この場合は単に git restore path/to/file で元の状態に戻してしまえばOKです。
ステージングに含めてしまったが、一部だけ取り消したい
不要なファイルを含めて git add . をしてしまったが、そのファイルはコミットに含めたくないといったケースです。
git restore --staged path/to/unnecessary_file でステージから外せます。
コード内容自体はワークツリーに残ったままなので、必要に応じてワークツリーの変更も併せて取り消すとよいでしょう。
既にコミットしてプッシュもしてしまった
リモートリポジトリに間違ったコミットを上げてしまったが、他のメンバーが同じリポジトリを使っているケースです。
git revert <コミットハッシュ> で「取り消しのコミット」を作り、履歴を上書きしない方法を選ぶのが無難です。
後から見返したときにも「なぜ取り消したのか」履歴がわかりやすくなります。
コミット取り消しと同時に、その理由をコミットメッセージに書いておくと、あとで履歴を追いやすくなります。
何度もやり直しをしたくない場合
複数のコミットをまとめて消したい・やり直したいときは git reset --hard <コミットハッシュ> で一気に巻き戻すこともあります。
ただし、冒頭でも触れたように、共同開発では慎重に検討してください。
まとめ
Gitでは「変更取り消し」といっても、状況や目的によってさまざまな方法が存在します。
ワークツリーの変更を取り消すなら git restore、ステージングエリアの変更を外すなら --staged、コミット後の履歴を修正するなら git revert や git reset と、段階ごとにコマンドが異なる点は注意が必要です。
特にチームで開発している場合、取り消し操作によっては履歴が大きく変わるため、周囲に影響を及ぼすことがあります。
そのため、作業内容を安全に取り消すためには、共同作業の流れやリポジトリの状況を考慮することが大切です。
みなさんが実務や個人プロジェクトでGitを使う際にも、今回紹介した「変更取り消し」の技術が役立つはずです。
ぜひ、取り返しのつかないトラブルを避けるためにも、落ち着いてコマンドの用途やオプションを確認してから実行してみてください。