↩️

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で飛ばした作業の復旧

参考資料