git reset と revert、どっちを使う？

結論：push済みかどうかで決まる

状況	使うコマンド
push前	`git reset`
push後	`git revert`

迷ったらrevert。履歴を壊さないので安全。

reset:  A → B → C → (Cを消す) → A → B
revert: A → B → C → (Cを打ち消す) → A → B → C → D

push済みのコミットをresetで消すと、リモートと履歴が食い違う。他の人がpullしたときに地獄になる。

# コミットだけ消す。変更はステージに残る
git reset --soft HEAD^

# コミットもステージも消す。変更はファイルに残る
git reset --mixed HEAD^

# 全部消す（危険）
git reset --hard HEAD^

**--hardは復元できない。**本当に捨てていいか確認してから。

git revert HEAD

エディタが開く。メッセージを確認して保存。

git revert abc1234

「間違えたからreset --hardしてforce pushすればいいや」

→ チームメンバーがすでにpull済み → 「履歴が壊れてpullできない」と連絡が来る → 全員にfetch --allとreset --hard origin/mainを依頼 → 作業中の人のローカル変更が消える

force pushは「チーム全員の作業を巻き込む」という意識がなかった。

正解はrevertでpushすること。履歴は増えるが、誰も困らない。

resetで消したい理由が「履歴を綺麗にしたい」なら、考え直す。

優先度	重要度
履歴の綺麗さ	低い
チームが困らないこと	高い

revertで打ち消しコミットが残っても、誰も困らない。困るのは履歴を書き換えたとき。

revert中にコンフリクトが起きることがある。

# コンフリクトを解決後
git add .
git revert --continue

# やっぱりやめる
git revert --abort

reflogに30日間残っている。

# 操作履歴を確認
git reflog

# 特定の状態に戻す
git reset --hard HEAD@{1}

ただし--hardで消したファイル変更は戻らない。

push済み？
├── はい → revert
└── いいえ
    └── 変更を残したい？
        ├── はい → reset --soft
        └── いいえ → reset --hard