【Git】元に戻す方法の完全ガイド！初心者向けにコミット取り消しやファイル復元をわかりやすく解説
はじめに
バージョン管理ツールのGitを使って開発していると、誤ってファイルを変更してしまったり、間違えたコミットをしてしまったりすることがありますよね。 こうした場面では、git 元に戻す作業が必須になってきます。
Gitでは目的に応じてさまざまな方法で変更をやり直すことができます。 この記事では、具体的なケースを取り上げて、コミットやファイル、ステージングの状態などを元に戻す方法をわかりやすく解説します。
この記事を読むとわかること
- Gitの変更を元に戻すための複数のコマンド例
- コミットを取り消す方法と、それぞれのメリット・デメリット
- ファイルの変更やステージングを取り消す手順
- 実務で役立つ変更の巻き戻しシナリオの考え方
変更を元に戻す作業とは？
Gitを使った開発では、過去の変更履歴やコミットがしっかりと記録されています。 しかし誤った変更や、まだ取り込みたくない内容がコミットされると、プロジェクト全体を混乱させてしまうかもしれません。
そういった場合に備えて、Gitでは変更を元に戻すための機能が豊富に用意されています。 「過去のコミットを打ち消したい」「個別のファイルだけ変更を取り消したい」「コミットに含めたくないものをステージングから外したい」といったニーズに応じてコマンドを使い分けます。
実務でよくある場面
- 機能Aを実装するはずが、テスト中に機能Bの変更をコミットしてしまった
- 一時的に作成したテストコードをうっかり取り込んでしまった
- 作業ブランチで行った変更をチームのブランチにマージした後、問題に気づいた
- コードレビューで指摘があり、直前の変更を打ち消す必要が出てきた
これらはいずれもgit 元に戻す操作が求められる典型的なシーンです。 そのため、基本的なコマンドを理解しておくとスムーズに開発を進められます。
コミットを元に戻す方法
コミットを元に戻す方法には主に次の2つがあります。 git revert と git reset です。 それぞれの違いをしっかり把握しておくと、後からトラブルなく履歴を管理できるでしょう。
git revert
git revert は「過去のコミットの変更を打ち消す」新たなコミットを作成する仕組みです。 リモートリポジトリに既にプッシュ済みのコミットを取り消すときに使われることが多いです。
たとえば、以下のようにしてコミットIDを指定します。
git revert <コミットID>
すると、指定したコミットの変更内容を元に戻す新しいコミットが作られます。 履歴を上書きせずに取り消したいときに便利です。
実務での活用シーン
- チームメンバーがプルした後に「やはりこのコミットは不要だった」と気づいた場合
- 共同開発中でコミットの履歴を書き換えることが不都合な場合
git reset
一方、git reset は、コミットの履歴そのものを巻き戻すイメージです。 すでに存在するコミットをなかったことにして、特定のポイントに作業ツリーを戻す操作が可能となります。
以下のようなコマンドで実行します。
git reset --hard <コミットID>
--hard オプションを付けると、作業ツリーも指定したコミットの状態に強制的に戻してしまいます。
まだリモートにプッシュしていないコミットを取り消すときによく使われます。
実務での活用シーン
- ローカルで作業中のコミットをやり直したいとき
- リモートに一切影響を与えずに、誤った作業をクリアにして再スタートしたい場合
git reset --hard は強力で、取り消したコミットやファイル変更が戻せなくなることがあります。 リモートで共有済みのコミットを reset すると履歴が食い違う原因になるため、基本的にはローカル作業時に限定した方が安全です。
ファイルの変更を元に戻す方法
「まだコミットしていないけれど、変更してしまったファイルを取り消したい」というケースでは、git restore や git checkout を使います。
git restore
git restore は Gitの比較的新しいコマンドで、ワークツリーやステージの変更を取り消す用途で使われます。 未コミットの変更を取り消すときは次のように実行します。
git restore <ファイル名>
これによって、指定したファイルは直前のコミット状態に戻ります。 つまり、変更を加える前の内容に巻き戻されるわけです。
実務での活用シーン
- 1ファイルだけ間違えた修正をしてしまったが、コミット前に取り消したい
- テスト的にファイルを書き換えたが、元に戻す必要が出てきた
git checkout
以前からよく利用されてきた方法に、git checkout コマンドでファイルを復元するやり方があります。 ブランチ切り替えにも利用されるため、実際には新しいコマンドである git switch と git restore を使うケースが増えていますが、環境によっては git checkout でファイルを戻すことも可能です。
コマンド例は次のようになります。
git checkout -- <ファイル名>
この操作で、指定したファイルが直前のコミットの状態に戻ります。
実務での活用シーン
- 古いGitバージョンを利用していて、git restore が使えないとき
- 過去のブランチで作業している場合に、特定ファイルを checkout で元に戻したいとき
ステージングを元に戻すには？
コミットこそしていないものの、git add でステージングに含めてしまった変更を取り消したい場合があります。 このときにも git restore が活躍します。
git restore --staged
ステージング領域からファイルを取り消したいときは次のように実行します。
git restore --staged <ファイル名>
これにより、ファイルがステージングから外れ、単なるローカルの変更扱いになります。
もし完全に変更も含めて戻したいなら、後述のgit restore <ファイル名> や git checkout も併せて利用します。
実務での活用シーン
- 間違ったファイルまで git add してしまったが、まだコミットはしていない
- まとめてステージングしてしまったが、一部だけ除外したい
変更を一時的に退避する（git stash）
「とりあえず手元の変更は残しておきたいが、別の作業ブランチに切り替えたい」といったケースでは、git stash を使います。
git stash
このコマンドを実行すると、未コミットの変更が一時的に退避されます。
必要になったら git stash pop で再度引き出して作業を再開できます。
実務での活用シーン
- 急ぎのバグ修正タスクが入り、作業中のローカル変更をコミットせずに中断したい
- 変更をまだコミットしたくないが、別ブランチの作業を先に行う必要がある
コミット履歴の確認でミスを防ぐ
変更を元に戻す操作を行う前に、コミット履歴をよく確認することが大切です。 どのコミットが誤りの原因になっているのかを特定した上で、必要最小限の変更に絞って取り消すようにしましょう。
コミット履歴のチェック
履歴を確認する際は、以下のように実行します。
git log --oneline
--oneline オプションを使うと、コミットIDとコミットメッセージが1行で表示されます。
誤ったコミットIDを指定して取り消してしまうと、修正が大きくややこしくなるので、慎重に確認するクセをつけたいものです。
コミット間の差分を見る
もしどのコミットに誤りがあったか判断に迷う場合は、git diff で差分を確認すると良いでしょう。
コミットIDを指定することで、該当箇所が一目瞭然になります。
git diff <コミットID>^ <コミットID>
ここで <コミットID>^ は一つ前のコミットを指します。
差分を確認してから git revert や git reset を行うと、無駄な取り消しを避けやすいです。
実務での活用事例
ここからは、具体的な活用事例を通して、どういった判断を行うかを見ていきましょう。
1. 誤ったコミットを既にプッシュしてしまった場合
すでにリモートへプッシュしてしまったコミットを取り消すときは、git revert を使います。 なぜなら、チームメンバーがすでにプルしている可能性があるため、履歴を上書きする git reset は混乱を招きかねないからです。
実行例:
git revert <コミットID>
これで、新しいコミットとして「取り消し」が適用されます。 チーム全員が同じ履歴を共有できるので、安全性が高い方法です。
2. ローカルの作業をまだプッシュしていない場合
誤ってコミットしてしまったけれど、まだリモートには送っていないという状態なら、git reset --hard が検討対象になります。
git reset --hard <コミットID>
このあと、git push をする前であれば、ほかの開発者には影響を与えません。
コミット履歴をきれいに保ちたい場面では重宝します。
ローカルにだけ残っているコミットを簡単に消し去りたい場合は、reset が便利です。 ただし、1つ前のコミットに戻すのではなく、特定のコミットの状態まで戻すためには、正確なコミットIDを指定する必要があります。
3. 一部のファイルだけ誤って編集した場合
まだコミットをしていない状態で、一部のファイルだけ元に戻したいときは、git restore <ファイル名> を使います。
取り消す必要があるファイルと、残しておきたいファイルを分けておけるため、細かな管理が可能です。
git restore <誤って編集したファイル名>
複数ファイルあればスペース区切りで列挙できます。 この操作だけで、直前のコミット状態へ戻すことができるので、細かい誤りをピンポイントで修正できます。
4. 既にステージングしたファイルを除外したい場合
間違えてgit add したファイルをコミット対象から外したいケースも多いです。
その場合は、git restore --staged <ファイル名> でステージングを解除できます。
git restore --staged <ファイル名>
解除してから、そのファイル自体の変更も戻したければ、さらに git restore <ファイル名> を実行するといいでしょう。
5. 途中の作業を一時退避して別ブランチで対応する場合
開発中に急な修正依頼や障害対応が入ることがあります。 その時点でコミットしたくない変更がある場合は、git stash で変更を退避しましょう。
git stash # 一時的にstashに保存される git checkout <別ブランチ> # 修正作業や障害対応 git stash pop # 再び変更を取り出す
これで、変更を元に戻す必要はなく、一時保管した状態でブランチを切り替えられます。
あとで再度作業ブランチに戻り、stash pop で継続できます。
「git 元に戻す」を安全に運用するコツ
Gitの巻き戻し関連のコマンドは非常に便利ですが、うまく使い分けないと取り返しのつかない事態を招くこともあります。
- マージ後の取り消しは、基本的に
git revertを利用する - まだリモートにプッシュしていない変更なら、
git reset --hardを検討 - コミットしない範囲でのファイル変更なら、
git restoreまたはgit checkout - ステージング外しは
git restore --staged - 万が一のためにブランチを新たに作って作業するのも安全策の1つ
特に、チーム開発の最中にはリモートリポジトリへの影響をよく考えましょう。
プッシュしたコミットを git reset --hard などで消すと、他の人の履歴と衝突を起こす可能性があります。
まとめ
Gitでの元に戻す操作は単純そうに見えて、実はコミットの状態やリモートへのプッシュ状況、作業ブランチの状況によって使い分けが求められます。
初心者の方はまず、git revert と git reset の大きな違いをしっかり理解してください。 コミット履歴を上書きせずに取り消すのか、履歴を巻き戻してなかったことにするのかで、使うコマンドは変わります。
ファイル単位、ステージング単位で戻すときには git restore が便利です。 古い環境であれば git checkout も利用できます。
また、作業を一時退避したいときには git stash があります。 作業中断や急なブランチ切り替え時に活躍するので、知っておくと開発がスムーズに進むでしょう。
以上のコマンドや手順を実務と結びつけて覚えていくことで、git 元に戻す操作に対する不安を減らすことができます。 今後、開発中に「しまった！」と思ったときに、ぜひ活用してみてください。