本質：git reset とは？
- ブランチが指すコミット（HEAD）を別のコミットに変更する。
- その際、ステージングエリアやワーキングツリーに与える影響を** オプション（
-soft,-mixed,-hard）で制御する。⇒ コミットやステージングのやり直しができる
オプション別挙動
| オプション | コミット（HEAD） | インデックス | ワークリリ |
|---|---|---|---|
| soft | 指定したコミットに移動する | 現在の編集を保持 | 現在の編集を保持 |
| mixed | 指定したコミットに移動する | ステージング解除(当時のコミット内容に準拠) | 現在の編集を保持 |
| hard | 指定したコミットに移動する | ステージング解除(当時のコミット内容に準拠) | 当時のコミット内容に準拠 |
使えそうなオプションとユースケース
◾ git reset --soft
- 想定状況：「コミットはしたけど、まだ手直ししたい」
- 使いどころ： 途中でコミットしてしまったものを、まとめ直してコミットし直す
- 補足： ステージング状態は維持されるので、即修正＆再コミットできる。
◾ git reset または git reset --mixed
- 想定状況：「ステージングしすぎた、いったん全部外したい」
- 使いどころ： ステージングが複雑になりすぎたとき
- 補足： ファイルの変更内容は残るため、安全性は高い。
◾ git reset --hard
- 想定状況：「とにかくすべてリセットしたい」
- 使いどころ： pull での想定外のブランチにマージしたとき、ファイル変種段階で大幅にやらかしたとき
git revert
-
目的：
「履歴を壊さずに過去の変更を取り消す」 -
挙動：
過去の変更履歴を打ち消すコミットを作る。
元のコミットはそのまま履歴に残るため、リモートブランチでも安全に使える。 -
例：
git revert HEAD~1
- ポイント：
直前のコミットを“逆の操作”で取り消す。
revert は履歴を改変しない。
公開済みのブランチでの「取消し」は必ず revert を使うべき。
注意：共有ブランチで reset は原則禁止。必ず revertする
- 共有ブランチで
resetを行うと、他人の履歴を書き換えることになる。 - → 代わりに
git revertを使うことで、元の履歴を保持しつつ取り消しが可能。
例：
# 最後のコミットを取り消す（履歴を残す）
git revert HEAD
git restore
-
目的：
「ワーキングツリーやステージングエリアの内容を元に戻す」(ファイル単位で変更を戻す) -
主な使い方：
git restore file
⇒ 作業ツリー（ファイルの中身）を最新のコミットに戻す（未ステージに戻す）
git restore --staged file
⇒ステージングからファイルを外す（git add を取り消す）
例：
git restore --staged file.txt
→ git add file.txt を取り消す。
git restore file.txt
→ 作業中の変更を破棄（上書き）する。
- ポイント：
reset の安全版。
ファイル単位で戻せるので、細かい調整・ステージングのやり直しに最適。
reset vs restore の個人的使い分け
| 目的 | 適切なコマンド | 理由 |
|---|---|---|
ステージング解除（git add を戻す） |
解除したいファイル数次第 |
reset で一気に戻したいとき以外はrestore 優先したほうが安全かも |
| 作業ファイルの変更を取り消す | git restore <file> |
reset より意図が明確、思わぬ範囲への影響防止 |
| コミットごと取り消したい | git reset --soft/mixed HEAD^ |
restore では履歴を戻せない |
reflog ＋ reset での復元
-
履歴が吹き飛んだように見えても、
reflogで戻せる
git reflog
# 例: HEAD@{2} などを確認して戻す
git reset --hard HEAD@{2}
まとめ
コミット・ステージングのや直しに強力。
push済のコミットの取消は必ず revert、ステージングのや直しは restore を基本にする。