Git に慣れてきて、初めて「間違えたコミットをした」「消してしまったかもしれない」場面に出会ったとき、検索結果には revert・reset・restore・reflog が並びます。どれが安全でどれが履歴を壊すのか分からず、reset --hard が怖くて手が止まる。この記事は、その選び方を一本の基準にまとめます。ブランチやマージの意味はすでに分かっている前提で、「間違えたあと」だけを扱います。
この記事の結論
- 直し方は、そのコミットを他の人が受け取っているかで決めます。
- 共有前なら、reset で枝の指す先を動かします。手元だけの話なのでやり直しが効きます。
- 共有済みなら、revert で打ち消しのコミットを足します。履歴は書き換えません。
- reset –hard と restore は、未コミットの変更を捨てます。実行前に状態を見ます。
- 消えたように見えても、reflog に動きの記録があり、既定では一定期間は戻せます。
- 直した内容は、あとで読める形（コミットメッセージ）に残します。
間違えたとき最初に見るものは何か｜状態と履歴を確かめる
最初にやるのは直すことではなく、見ることです。慌てて操作を重ねると、元の状態が分からなくなります。
git status # 作業ツリーとステージの状態
git log --oneline -5 # 直近のコミット
git branch -vv # 枝がどのリモートの枝を追っているか
見るのは3点です。
- 未コミットの変更があるか。 あるなら、これから使う操作で消えないかを先に考えます。
- 間違えたコミットはどれか。 直前の1つか、少し前か。マージコミットか。
- そのコミットはもう共有したか。
git branch -vvの表示や、リモートの枝との差を見て、push 済みかを確かめます。push していても、誰も取り込んでいないとは限りません。迷ったら「共有済み」として扱うのが安全です。
この3つが分かれば、使う道具はほぼ決まります。
直す前の流れ
道具を選ぶ前に、状態を見て共有したかを確かめる
-
気づく
間違いに気づいて手を止める
-
見る
status と log で状況を見る
-
共有したか
push・取り込みの有無
-
reset か revert
手元だけ→reset／共有済み→revert
-
確かめる
log で結果を見る
CHECK 1ここまでの確認
すでに push して他の人が受け取ったかもしれないコミットを取り消すとき、向いているのはどちらか?
答えと解説
答え: 2. revert で打ち消しのコミットを足す
revert は履歴を書き換えず、打ち消しを新しいコミットとして足します。受け取った人の履歴と食い違いません。読み直す場所は「共有したあとなら」です。
共有する前ならどうするか｜reset で枝を動かす
ブランチは、コミットを指す軽い「しおり」でした。reset はこのしおりの指す先を別のコミットに動かす操作です。まだ手元にしか無いコミットなら、しおりを戻すだけで「無かったこと」にできます。
git reset --soft HEAD~1 # 直前のコミットだけ取り消す。変更はステージに残る
git reset HEAD~1 # --mixed（既定）。変更は作業ツリーに残る
git reset --hard HEAD~1 # 変更ごと捨てる
HEAD~1 は「1つ前のコミット」です。違いは、どこまで巻き戻すかにあります。
| 種類 | 枝の指す先 | ステージ | 作業ツリー（ファイルの中身） |
|---|---|---|---|
--soft |
戻る | そのまま残る | そのまま残る |
--mixed（既定） |
戻る | 戻る（コミット前の状態） | そのまま残る |
--hard |
戻る | 戻る | 戻る＝変更が消える |
reset の3段
reset は どこまで戻すかを soft・mixed・hard で選ぶ
-
soft
コミットだけ戻る
変更はステージに残る
-
mixed
コミットとステージが戻る
変更は作業ツリーに残る（既定）
-
hard
作業ツリーまで戻る
未コミットの変更が消える
コミットの文面を直したいだけ、コミットを分け直したいだけなら --soft か --mixed で足ります。ファイルの中身が残るので失うものがありません。--hard だけが作業ツリーまで書き換えるので、まだコミットしていない変更が混ざっているときは使う前に git status で確かめます。
reset は「履歴を書き換える」操作でもあります。共有前なら自分しか困りませんが、すでに他の人が受け取ったコミットを reset で消して push し直すと、相手の履歴と食い違います。次の節の revert が必要になるのはこの場面です。
CHECK 2ここまでの確認
revert を実行したあと、履歴に新しく残るものは何か?
答えと解説
答え: 1. 元の変更を打ち消す内容の新しいコミット
元のコミットは履歴に残ったまま、その逆の変更を持つコミットが1つ増えます。履歴は消さずに足す方式です。
共有したあとならどうするか｜revert で打ち消しを足す
git revert は、指定したコミットの変更を打ち消す内容の新しいコミットを作ります。元のコミットは履歴に残ります。Git の公式ドキュメントも、revert は既存のコミットを取り除くのではなく、打ち消しを足すものだと説明しています。
git revert <コミットID>
履歴は次のように伸びます。
| 操作 | 履歴の変化 | 受け取った人の履歴との関係 |
|---|---|---|
| reset | 枝が指す先が戻り、後ろのコミットは枝から外れる | 食い違う（共有済みでは避ける） |
| revert | 打ち消しのコミットが1つ増える | 食い違わない（そのまま取り込める） |
共有前と共有後
手元だけなら reset、共有したなら revert
共有前（手元だけ）
reset：枝の指す先を動かす
- 枝が1つ前を指す
- やり直しが効く
- push し直すと相手と食い違う
共有後
revert：打ち消しを足す
- 打ち消しのコミットが増える
- 元の履歴は残る
- 受け取った人がそのまま取り込める
マージコミットを revert するとき
マージコミットは親が2つあるため、どちらの親の側に戻すのかを -m で指定します。
git revert -m 1 <マージコミットID>
-m 1 は、1番目の親（多くの場合、取り込み先の枝の側）を「残す側」とする指定です。どの親が何かの判断は公式ドキュメントの -m の説明で確かめてください。あとで同じ枝をもう一度マージしたいときは、revert した変更が効いている点にも注意が必要です。ここは扱いが込み入るので、必要になったときに公式へ当たります。
秘密情報を push してしまったとき
revert は履歴を消しません。パスワードやアクセスキーを含むコミットを push した場合、revert しても元のコミットから読めます。認証情報を先に無効化するのが第一です。履歴からの除去の手順は GitHub の公式ドキュメントで確かめてください。
CHECK 3ここまでの確認
reset --hard で枝が戻ったあと、前の位置を探す手がかりになるのはどれか?
答えと解説
答え: 2. reflog
reflog は枝や HEAD が指す先の動きを記録しています。コミット済みの分ならそこから位置を見つけられます。読み直す場所は「消えたと思ったら」です。
消えたと思ったら？ reflog とは何か｜動きの記録と残る期間
reset --hard のあとにコミットが一覧から消えると、失ったように見えます。けれど、Git は枝や HEAD が指す先の動きを reflog に記録しています。
git reflog
出力には、HEAD が過去にどのコミットを指していたかが新しい順に並びます。戻したい時点の ID が見つかれば、そこへ枝を動かせます。
git reset --hard <reflog で見つけた ID>
reflog の記録は永遠ではありません。公式ドキュメントによると、既定の保持は、枝から到達できるものが90日、到達できなくなったものが30日です。設定で変わるので、自分の環境の値は設定を確かめます。
注意が2つあります。
- reflog は自分のリポジトリの手元の記録です。別の人のクローンや、リモートの側には同じものがありません。
- 記録されるのはコミットした内容だけです。コミットしていなかった変更は reflog に入らないので、
reset --hardで捨てると戻せません。
CHECK 4ここまでの確認
未コミットの変更を捨てる操作の前に、まずやることは何か?
答えと解説
答え: 2. status などで捨てる中身を確かめる
未コミットの変更は履歴に入っていないので、捨てると reflog にも残らず戻せません。実行前に中身を見ます。
作業中の変更を戻すには｜restore と stash の使いどころ
コミットの前の、作業ツリーの変更を戻す道具もあります。
| 道具 | 何をするか | 変更は残るか |
|---|---|---|
git restore <ファイル> |
ファイルをステージ（または HEAD）の状態に戻す | 捨てる（戻せない） |
git stash |
変更をいったん脇に退避して、作業ツリーをきれいにする | 残る（あとで取り出せる） |
迷うなら stash を先に使います。退避なら、あとで必要だと気づいても取り出せます。restore は捨てる操作なので、実行前に git status と git diff で、何が消えるかを見ます。
運用の約束事は何か｜main を守る・force push しない・理由を残す
道具の使い分けに加えて、チームで間違いを小さくする約束事があります。
- main に直接 push しない。 ブランチとプルリクエストを通せば、間違いが main に入る前にレビューで止められます。
- 共有済みの履歴に force push しない。 reset で戻した枝を push し直す操作は、受け取った人の履歴を壊します。やむを得ないときは、影響する人に先に伝えます。
- 直した理由をコミットメッセージに残す。 revert のメッセージには、何を打ち消したか・なぜかを書きます。あとで履歴を読む人が、打ち消しの意図を追えます。
- 直す前に状態を確かめる。
statusとlogを見てから操作します。
Cloudory 執筆者（AWS 認定 全冠）
基準は1つです。「そのコミットを、誰かがもう受け取っているか」。受け取っていなければ reset、受け取っていれば revert。迷ったら revert を選べば、履歴が壊れることはありません。
まとめ
- 間違えたら、まず
statusとlogで見て、共有したかを確かめる。 - 共有前は reset（soft / mixed / hard で戻す範囲を選ぶ）、共有後は revert。
- 消えたように見えても、コミット済みなら reflog から探せる。保持は既定で90日（到達可能）と30日（到達不能）。
- 未コミットの変更を捨てる操作は、実行前に中身を確かめる。
- 次は、間違いが main に入りにくくなる仕組みとして、CI/CD を読むとつながります。
READ ALSO — 学習中向け・段2 構成
CI/CD の仕組み｜コミットから本番まで、ビルド・テスト・デプロイが自動で流れて止まる理由
参照ソース
- git-revert Documentation — revert が打ち消しのコミットを足して履歴を保つこと、reset との違い、マージコミットの
-m（2026-10 時点） - git-reflog Documentation — reflog が参照の動きを記録すること、既定の保持（到達可能 90 日・到達不能 30 日）の根拠
- git-reset Documentation — reset の soft / mixed / hard が戻す範囲の根拠
