↩️
reset vs revert、何をいつ使うか
履歴を書き換える vs 打ち消しコミットを追加する
両方とも『元に戻す』だが、やり方が全く違う。
reset
ブランチポインタを指定コミットに移動する。それ以降のコミットは履歴から消える(オブジェクトはreflogに残る)。
--soft: HEADのみ移動。変更はstaged状態のまま--mixed(デフォルト): HEAD移動 + index リセット。変更はworking treeに残る--hard: HEAD移動 + index + working tree全部リセット。復旧困難
revert
指定コミットの逆変更を含む新しいコミットを作る。履歴はそのまま残り、末尾に『打ち消しコミット』が1つ追加される。
選択基準
まだpushしていない? resetがすっきり。
既にpushした? revertを使う。resetしてforce pushすると他人の履歴が壊れる。
ミス復旧
git reset --hardで何かを飛ばしても慌てない。git reflogに最近のHEAD移動履歴が残っている。目的のハッシュにresetし直せば戻る。デフォルト30日保持。
動作フロー
1
`git reset --soft HEAD~1` → 最後のコミット取消、変更はstaged維持
2
`git reset --hard <hash>` → 指定コミットに完全初期化(危険)
3
`git revert <hash>` → 該当コミットを取り消す新コミット生成
4
`git reflog` → HEAD移動履歴を確認、ミス復旧に使う
メリット
- ✓ reset: 履歴が綺麗に消える
- ✓ revert: 安全、協業履歴を壊さない
デメリット
- ✗ reset: 共有ブランチで使うと危険
- ✗ revert: 履歴に打ち消しコミットが残る
ユースケース
reset: push前のローカルコミット整理
revert: 既にデプロイされた問題コミットの取り消し
reflog: --hardで飛ばした作業の復旧