開発の現場で誰しも一度は経験するのが、「まだコミットするはずではなかったファイルをコミットしてしまった」「誤ったコミットメッセージで記録してしまった」というトラブルです。特に焦るあまり、書いたコードまで吹き飛ばしてしまわないか不安に駆られるエンジニアは少なくありません。
Gitの操作ミスは、仕組みさえ理解していれば恐れる必要は一切ありません。変更内容を手元に残したまま直前のコミットだけをなかったことにする手法から、リモートリポジトリへプッシュした後の安全な打ち消し方まで、現場ですぐに役立つ実践的なリカバリー手順を徹底解説します。
📌 【この記事の重要ポイントまとめ】
- 要点1：作業中のコードを残して直前のコミットを取り消すなら
git reset --soft HEAD~1が鉄板の解決策。- 要点2：共有リポジトリへのpush前はreset、push後はrevertを使い分けるのがチーム開発の鉄則。
- 要点3：メッセージ修正やファイルの含め忘れだけなら、余計なキャンセルを挟まず
git commit --amendで上書きするのが最速。
【緊急対応】変更を残して直前のコミットを取り消す「決定打コマンド」
「コミットを取り消したいけれど、書いたコードや修正内容は絶対に消したくない」という場面で使うべきコマンドが、git reset --soft HEAD~1です。このコマンドを実行すると、コミット履歴だけが1つ前に巻き戻り、コミットに含まれていた変更内容は「ステージングされた状態（git addされた直後の状態）」でそのまま残ります。
たとえば、以下のコマンドを実行するだけで安全にコミット前の状態へと復帰できます。
git reset --soft HEAD~1実行後にgit statusを確認すると、直前のコミットで記録したファイルが緑色の文字（Staged状態）で保持されていることが分かります。もし「ステージングも解除して作業ツリーの変更状態（未ステージング）に戻したい」という場合は、オプションを--mixed（またはオプション省略）に変更して実行してください。
誤って作業ファイルを丸ごと消去してしまう恐れがある--hardオプションとは異なり、--softや--mixedは作業データを一切破壊しないため、日常の開発におけるコミットやり直しにおいて最も安全な選択肢です。
push前とpush後で何が変わる？「reset」と「revert」の決定的違い
コミットのキャンセル作業を行う際、最初に確認しなければならないのが「すでにリモートリポジトリへpushしてしまったかどうか」という点です。ここを見誤ると、チームメンバーのローカル環境と履歴が衝突し、重大なコンフリクト事故を引き起こす原因になります。
ローカル環境だけで完結しているpush前であれば、前述のgit resetを使って過去のコミット履歴そのものを消去・改変しても問題ありません。しかし、一度GitHubやGitLabなどの共有ブランチへpushしたコミットは、すでに他の開発者がプルして作業を進めている可能性があります。
push後のコミットを取り消す場合は、履歴を書き換えるresetではなく、変更を打ち消す新しいコミットを作成するgit revertを採用するのが基本原則です。resetとrevertの本質的な違いは「過去の履歴を消し去るか」「打ち消したという事実を新しい履歴として残すか」にあります。共有ブランチの歴史を壊さないためにも、pushの有無に応じた使い分けを徹底しましょう。
コミットメッセージの修正や追加漏れなら「git commit --amend」で十分な理由
コミットそのものを完全にキャンセルしたいわけではなく、「タイポしたコミットメッセージを直したい」「1ファイルだけgit addを忘れてコミットしてしまった」というケースも多々あります。このような軽微な修正に対して、わざわざresetを実行してコミットを作り直すのは手数が多く非効率です。
直前のコミット内容を上書き・修正したいときは、git commit --amendを活用するのがスマートです。
メッセージだけを書き直したい場合は、以下の1行でエディタを開かずに修正できます。
git commit --amend -m "新しいコミットメッセージ"ファイルの追加漏れがあった場合は、追加したいファイルを通常通りgit addした上でgit commit --amend --no-editを実行します。--no-editをつけることで、既存のコミットメッセージを維持したまま、漏れていたファイルだけを直前のコミットへと綺麗に統合できます。
【要注意】「--hard」で作業データが消えた場合の復元テクニック
不用意にgit reset --hard HEAD~1を実行してしまい、「作業中のファイル変更まで完全に消去されてしまった」と頭を抱えるケースがあります。--hardは作業ツリーの変更も含めてすべて指定位置の状態へと強制的に戻すため、一見するとコードが消失したように見えます。
しかし、一度でもコミットとして記録されたデータであれば、Gitの内部ログであるgit reflogから救出できる可能性が極めて高いです。
上記を実行すると、HEADの移動履歴が一覧で表示されます。たとえばHEAD@{1}がreset直前のコミットハッシュである場合、以下のコマンドでその時点の状態を丸ごと復元可能です。
Gitはコミットされたオブジェクトを一定期間ガベージコレクションせずに保持しているため、パニックを起こさずにreflogを確認することが生還への近道となります。
リモートにpushしてしまったコミットを安全に取り消す「git revert」完全ガイド
すでにリモートブランチへプッシュ済みのコミットを取り消す際は、前述の通りgit revertを使用します。指定したコミットの変更差分を完全に反転させる「打ち消しコミット」を生成するため、安全に差分を元に戻せます。
直前のコミット（HEAD）を打ち消す場合は、以下のコマンドを実行します。
git revert HEADエディタが立ち上がり、「Revert "コミット名"」といったデフォルトのコミットメッセージが表示されるので、保存して閉じるだけで取り消しコミットが作成されます。特定の古いコミットを指定したい場合は、コミットハッシュを指定してgit revert を実行してください。
生成された打ち消しコミットを通常通りリモートへgit pushすれば、他の開発者のブランチに影響を与えることなく、安全に本番環境や共有環境のコードを以前の状態へ巻き戻すことができます。
過去のコミット履歴をさかのぼって修正したい場合の「git rebase -i」活用法
直前ではなく「3つ前のコミットメッセージを修正したい」「複数のコミットを1つにまとめたい」といった、少し過去の履歴に対する操作にはインタラクティブ・リベース（git rebase -i）が威力を発揮します。
たとえば過去3件の履歴を対象にする場合、以下のコマンドを実行します。
git rebase -i HEAD~3テキストエディタが開き、古い順にコミット一覧が表示されます。修正したいコミットの先頭にあるpickの文字を以下のように書き換えて保存します。
edit（またはe）：コミット内容やメッセージを直接修正して一時停止するreword（またはr）：コミットメッセージのみを書き直すsquash（またはs）：1つ前のコミットと統合するdrop（またはd）：そのコミット自体を完全に削除する
editを指定した場合は、ファイル修正後にgit commit --amendを行い、最後にgit rebase --continueを実行することで、指定位置の履歴を綺麗に整えることができます。ただし、こちらも履歴改変を伴うため、ローカルブランチ内での作業に限定するのが鉄則です。
【git commit 取り消し】に関するよくある質問（FAQ）
Q1：git reset HEAD~1とgit reset HEAD^に違いはありますか？
A1：直前の親コミットを指す意味において、通常の1コミット前の指定であれば両者に動作の違いはありません。~1は「1世代前」、^は「1番目の親」を意味します。マージコミットなど複数の親を持たない限り、どちらを使っても直前のコミットを取り消せます。
Q2：取り消しを実行したのにファイルがエディタ上で変更されたまま残っています。失敗ですか？
A2：失敗ではありません。--softや--mixedでresetした場合、変更したコードを消去しないよう作業ツリーに残す仕様になっています。不要なファイルであれば手動で削除するか、git restore <ファイル名>で変更を破棄してください。
Q3：push済みのコミットをgit resetしてgit push -fで上書きしては駄目ですか？
A3：自分1人だけが使っている個人ブランチ（作業用Featureブランチなど）であれば許容されるケースもあります。しかし、チームで共有しているブランチ（mainやdevelop）で強制プッシュ（force push）を行うと、他メンバーのローカル履歴と乖離し、最悪の場合他人のコードを消し去る恐れがあるため厳禁です。
まとめ：状況に応じたコマンド選択で開発トラブルをゼロに
Gitのコミット取り消しは、状況に合わせた適切なコマンドを選ぶことが何よりも大切です。変更内容を残したいときはgit reset --soft、メッセージや追加漏れの修正にはgit commit --amend、そして共有ブランチへのpush後はgit revertを選択する――この3つの基本パターンを押さえておくだけで、日々の開発におけるミスの9割以上は安全にリカバリーできます。
万が一作業データが意図せず消えた場合でも、git reflogを使えば元のコミットを救出可能です。焦って無闇にコマンドを連打せず、現在のブランチ状態とpush状況を冷静に見極めながら適切な手順で対処していきましょう。 （出典: git commit 取り消し（Yahoo!ニュース））