定期実行・自動化 2026年10月25日 10分で読めます

Gitで元に戻す方法｜リセットとrevertの使い分け早見表

Gitで元に戻す方法｜リセットとrevertの使い分け早見表

Gitで元に戻す方法を調べると、`git reset`、`git revert`、`git restore` と似たコマンドが出てきて、どれを使えばいいか迷いませんか？

この記事では、Gitのリセット（reset）とrevertの使い分けを、検証用リポジトリで実際に試した結果と一緒に整理します。最後に、Claude Codeに安全に相談するプロンプトも載せています。

※2026年10月25日時点の情報です。環境はmacOS・Git 2.33.0で、バージョンや設定により表示が異なる場合があります。Gitコマンドはターミナル、プロンプト例はClaude Codeのチャット欄で使う想定です。

結論：push前ならreset、push後ならrevert

一言で言えば、まだpushしていないコミットは `git reset`、もうpushしたコミットは `git revert` が基本です。

下の表のreset例は、直前の1コミットだけを取り消す場合です。もっと前のコミットまでresetすると、そのあとのコミットも現在のブランチの履歴から外れます。

状況	使うコマンド	現在のブランチの履歴
直前のコミットを取り消して、変更はそのまま残したい（push前）	`git reset –soft HEAD~1`	外れる
コミットもaddも取り消して、ファイルの変更だけ残したい（push前）	`git reset HEAD~1`	外れる
コミットも変更も丸ごと捨てたい（push前）	`git reset –hard HEAD~1`	外れる
pushしたコミットを取り消したい	`git revert <コミットID>`	残る（打ち消しコミットが増える）
まだaddしていないファイルの編集を捨てたい	`git restore — <ファイル名>`	関係なし

※`git restore` はGit 2.23以降のコマンドです。古いGitでは `git checkout — <ファイル名>` が同じ役割を持ちます。コミットの位置を動かす用途では、resetは今も現役です。

`HEAD~1` は「今いるコミットの1つ前」という意味です（最初のコミットしかない場合は使えません）。

表の中の `–hard` と `git restore` は、編集を破棄する操作です。 restoreは指定ファイルのaddしていない編集、`–hard` は追跡ファイル全体のコミットしていない編集に影響します。

restoreは「【Git実践】git restoreで”なかったことに”する」で詳しく書いたので、今回はコミットしたあとに戻す方法に絞ります。

git resetの3つのモードを実際に試した

`git reset` はブランチの位置を過去のコミットへ戻すコマンドで、オプションにより手元の変更の残り方が変わります。

検証用フォルダで `memo.txt` に3回コミットし、3回目を「間違えて追加」としました。各モードの前に3回目のコミットをやり直し、毎回同じ状態から実行しています（続けて実行すると、さらに前へ戻ってしまいます）。


git log --oneline
# f721e47 間違えて追加
# 8728270 2行目を追加
# 76f65f7 最初のメモ

–soft：コミットだけ取り消す


git reset --soft HEAD~1
git status --short
# M  memo.txt

コミットはブランチの履歴から外れましたが、変更はaddした状態（ステージ済み）のまま残りました。コミットし直したいときに向いています。

–mixed（オプションなし）：addも取り消す


git reset HEAD~1
# Unstaged changes after reset:
# M	memo.txt

オプションを付けないと、この `–mixed` になります。コミットもaddも取り消され、ファイルの中身だけが変更済みで残る状態です。

–hard：変更も丸ごと捨てる


git reset --hard HEAD~1
# HEAD is now at 8728270 2行目を追加

`memo.txt` を開くと、「間違い」の行がきれいに消えていました。

注意したいのは、`–hard` はまだコミットしていない編集も消してしまうことです。実行前に、次のコマンドで「取り消すコミット」と「未コミットの変更」を確認しておくと安心です。


git log --oneline -2       # 取り消すコミットと、戻る先のコミット
git diff HEAD~1 HEAD       # 取り消すコミットの変更内容
git status --short --untracked-files=all  # 未コミットの変更・未追跡ファイルの一覧
git diff                   # まだaddしていない変更の中身
git diff --cached          # add済みの変更の中身

残したい変更があれば、先に `git stash push -u` で退避してください（`-u` で未追跡ファイルも対象になります）。戻す先のファイルと同じ場所にある未追跡ファイルは削除・上書きされる場合があり、`.gitignore` で除外した大事なファイルは別の場所へコピーしておくと確実です。`git stash list` で退避を確認してからresetしましょう。戻し方は後述のstash記事にあります。

消したコミットはreflogで戻せることがある

試しに `git reflog` を見ると、resetする前のコミットIDが残っていました。


git reflog
# 8728270 HEAD@{0}: reset: moving to HEAD~1
# f721e47 HEAD@{1}: commit: 間違えて追加

この `f721e47` を指定すれば、履歴から外れたコミットに戻れる可能性があります。まず `git branch rescue-reset f721e47` のように別ブランチを作れば、今の作業を上書きせずに保護できます（名前は任意）。ただし復旧できるのは一度コミットしたものだけで、未コミットの変更を `–hard` で消した場合は戻せません。

reflogの使い方は「【Git実践】reflogとstashでやらかしを復旧する」にまとめています。

pushしたあとはgit revertで元に戻す

pushしたあとのコミットに `git reset` を使うと、手元とGitHubの履歴が食い違います。reset後の手元の履歴でGitHub側を上書きするには、通常 force push（強制的な上書き）が必要になり、チームで使っているブランチだと他の人の作業に影響が出るおそれがあります。

そこで使うのが `git revert` です。revertは「そのコミットの変更を打ち消す、新しいコミット」を作るコマンドです。


git revert --no-edit HEAD
# [main 31ac27b] Revert "3行目を追加"

git log --oneline
# 31ac27b Revert "3行目を追加"
# ad28b5e 3行目を追加
# 8728270 2行目を追加

作業中の変更がない状態で、直前のコミットを取り消した例です。「3行目」は消えましたが、履歴には「追加」「取り消し」の両方が残ります。履歴を書き換えないので、普通に `git push` できます。

古いコミットを取り消すと競合が起きることがあり、困ったら `git revert –abort` で中止できます。マージコミットは親の指定（`-m`）が必要なので、Claude Codeに状況を見てもらうのがおすすめです。

Gitの公式ドキュメント（git revert）では、revertのコミットメッセージには自動生成のままではなく、取り消した理由を書くことが推奨されています。`–no-edit` は編集を省くオプションなので、練習以外では外して理由を書きましょう。

Claude Codeの/rewindとGitの違い

Claude Codeを使っている方は、`/rewind`（またはプロンプト入力欄が空の状態でEscキーを2回）でも変更を巻き戻せます。ファイルを戻すときはメニューで「Restore code」系を選びます。

ただ公式ドキュメント（Checkpointing）によると、これはセッション単位のチェックポイントです。再開後も保持期間内なら使えますが、対象は主にClaudeのファイル編集ツールによる変更で、Bashだけで変更したファイルやClaudeが触っていないファイルの手作業は基本的に追跡されません。逆に、Claudeが編集したファイルへの後からの手作業は一緒に戻る場合があります。公式にも「バージョン管理の代わりではない」とあります。

今のところ、私は次のように使い分けるつもりです。

Claudeに頼んだ直後の編集が微妙だった → `/rewind`
コミットした内容を取り消したい → `git reset` / `git revert`

Claude Codeに「どう戻すか」を相談するプロンプト

正直、試したあとでもsoft・mixed・hardをとっさに思い出せる自信はまだありません。迷ったらClaude Codeに状況を調べてもらい、実行は自分で確認してからにするつもりです。次のプロンプトをチャット欄に貼って使ってみてください。


間違えてコミットした内容を取り消したいです。
対象はこのリポジトリの現在のブランチだけです。

まず以下を確認して、結果を見せてください（この段階では何も変更しないでください）。
1. git status と git log --oneline -5 の結果
2. 取り消したいコミットがすでにpush済みかどうか（追跡先のリモートブランチや、そのコミットを含むブランチも確認してください。情報が足りない場合は未pushと断定しないでください。git fetchが必要なら、実行前に理由を説明してください）
3. コミットしていない変更が残っているかどうか

取り消すコミットIDは私に確認してください。そのあとにも別のコミットがある場合は、その扱いも確認してください。
対象コミットの変更を「残したい」か「捨てたい」かは、私に質問してください。私が答えるまで、変更を破棄する方法（reset --hardなど）は選ばないでください。

そのうえで、reset（soft / mixed / hard）とrevertのどれが適切かを、理由と一緒に提案してください。

reset・revert・pushなど履歴やファイルを変更する操作を実行する前に、対象のコミット一覧、差分、影響範囲を表示してください。私が確認してから実行してください。
force pushは提案しないでください。必要そうな場合は理由だけ説明してください。
不明点があれば推測せず、確認事項として列挙してください。

「調べる」と「実行前に確認する」を分けることで、いきなり `–hard` が走る心配を減らせます。

まとめ：Gitで元に戻す方法の選び方

push前のコミットを取り消すなら `git reset`
変更を残すなら `–soft`（ステージ済み）か `–mixed`（未ステージ）
`–hard` はコミットしていない編集も消えるので、実行前に `git status` と `git diff` を確認
push後のコミットは `git revert` で打ち消しコミットを作る
Claude Codeの `/rewind` はセッション単位のチェックポイント。Gitの代わりにはならない

実際に戻してみて「どこまで戻るのか」が目で見てわかったのは大きな収穫でした。本番の作業フォルダではなく、新しいフォルダで `git init` して3回コミットした検証用リポジトリで一度試してみるのがおすすめです。

このトピックをアプリで試す

取り消し操作は、読むより手を動かすほうが早く身につきます。本物のターミナルで練習できる「Git学習アプリ」をGitHubで公開しています。現在はREADMEに沿って手元のPCで起動する形です（macOS / Linux、Node.js 20以上。Windowsは非対応）。第6章「やり直す（restore）」や、取り消し・復旧（reset・revert・reflogなど）の実践ドリルで試せます。ブラウザだけで使えるWebアプリ版（app.maahsachi.com 予定）は公開準備中です。