AIが出したgit reset --hardやpush --forceを実行する前の確認表

まず確認表:コマンド別に消える物・退避・復旧

次の表は、公式ドキュメントの記述と、それに基づく編集上の提案をまとめたものです。コマンド例は本記事のために書いたもので、実際のリポジトリで実行して確かめた結果ではありません。

• git reset --hard <commit>、消える・上書きされる物：作業ツリーとインデックスを指定コミットの内容で上書き。ステージ済みの変更も消える。指定コミットにない追跡済みファイルは削除され、未追跡ファイルが上書きされる場合もある、実行前の退避：変更をコミットするか、git stash push -u で未追跡も含めて退避。現在位置にブランチを作る、復旧手段：コミット済みの分は git reset --hard ORIG_HEAD や reflog から戻す。未コミットの変更は戻せない前提で考える
• git push --force、消える・上書きされる物：リモートのブランチ先端を上書き。他の人が積んだコミットがブランチから外れる、実行前の退避：上書きされるリモートの現在のSHAを控える。必要ならバックアップ用ブランチをリモートに作る、復旧手段：古いSHAを持つクローンがあれば、そこからブランチを作り直す。SHAを控えていないと探すのが難しくなる
• git push --force-with-lease、消える・上書きされる物：--force と同じ上書きだが、リモートが想定と違えば拒否される、実行前の退避：直前に git fetch し、origin/ブランチ名 の位置を確認する、復旧手段：--force と同じ
• git clean -fd(-x 付きも)、消える・上書きされる物：未追跡のファイルとディレクトリ。-x では無視設定のファイルやビルド成果物も対象、実行前の退避：git clean -n で一覧を確認。必要な物はコピーか stash -u、復旧手段：Gitの管理外なので、Gitからは戻せないと考える

表の根拠は、git reset、git push、git cleanの各公式ドキュメントです。以降で各行を説明します。

git reset --hard:消えるのは「まだ記録していない変更」

公式ドキュメントでは、--hard は作業ツリーのすべてのファイルとディレクトリを指定コミットの版で上書きし、インデックスも合わせます。ステージ済みの変更もなくなります。未追跡ファイルを上書きすることがある、とも書かれています。

つまり危険なのは、過去のコミットに戻ること自体より、指定コミットの状態に合わせて作業ツリーとインデックスが上書きされることです。ステージ済みの編集や、指定コミットにない追跡済みファイルも対象です。AIに直してもらっている途中のファイルがあれば、それも対象です。

実行前の退避

次のコマンドは説明用の例です。ブランチ名は任意です。

# 1. 何が未コミットかを見る
git status --short

# 2. 今のコミット位置に目印のブランチを作る
git branch backup/before-reset

# 3. 未追跡も含めて退避する(作業ツリーはきれいになる)
git stash push -u -m "before reset"

git stash は、公式ドキュメント上、既定では追跡済みの変更だけを対象にし、新規の未追跡ファイルも守るには -u(--include-untracked)が必要です。なお、stash は退避であって安全な保管ではありません。resetを済ませたら git stash pop で戻すところまでを手順に含めてください。

復旧の手段

コミット済みの履歴を動かしてしまった場合は、次の方法があります。

• resetの直前の位置は ORIG_HEAD に保存されます。公式ドキュメントにも git reset --hard ORIG_HEAD で戻す例があります。ただし他の操作で上書きされることがあるので、上の目印ブランチのほうが確実です。
• git reflog で以前のHEADの位置を探せます。git reflog によると、期限切れの既定は90日、到達できないエントリは30日です。reflogは手元のリポジトリだけの記録で、pushやpullでは共有されません。

一方、コミットしていない変更はreflogに載りません。reflogは「参照の先端がいつ動いたか」の記録だからです。ここが --hard の最大の落とし穴です。

範囲を狭めたい場合

目的が「最後のコミットを取り消したい」だけなら、AIに --keep で足りないか聞いてみてください。公式の説明では、--keep は作業ツリーの変更を残すための指定で、衝突しそうなときは中断します。--hard よりは安全側ですが、条件に合わないと実行できません。

git push --force:消えるのは「自分以外の履歴」かもしれない

--force は通常の安全確認を無視して更新します。git push には、リモートがコミットを失ったり、他の開発者が土台にした履歴が消えたりし得ると書かれています。上書きされたコミットは、名前の付いたブランチから外れ、git gc で消える可能性もあります。

実行前の退避

git fetch origin
# 上書きされる側の現在位置を控える(説明用の例)
git rev-parse origin/feature-x
# 退避用ブランチをリモートに作る
git push origin origin/feature-x:refs/heads/backup/feature-x-before-force
# 実際には送らずに結果を見る
git push --dry-run --force-with-lease origin feature-x

--dry-run は更新を送らずに、何が起きるかを確認するオプションです。バックアップ用ブランチの作成は編集上の提案で、チームのルールで禁止されていないか先に確認してください。

--force ではなく --force-with-lease

--force-with-lease は、リモートが想定した位置のときだけ上書きします。他の人が先に積んだコミットを巻き込みにくくなります。ただし公式ドキュメントは、バックグラウンドで git fetch が走る環境では危険になり得ると注意しています。この場合は --force-if-includes を併用し、取り込み済みかを確認できます。

git push --force-with-lease --force-if-includes origin feature-x

mainなどの共有ブランチ

GitHubの保護ブランチでは、ブランチ保護ルールは既定でforce pushを無効にします。管理者が許可した場合は、書き込み権限以上の全員か、指定したユーザー・チーム・アプリが実行できます。共有ブランチへのforce pushをAIが勧めてきたら、手を止めて保護設定とチームの手順を確認してください。

git clean:Gitに戻す手段がない

AIは git reset --hard && git clean -fd と続けて出すことがあります。git clean は未追跡ファイルを消すコマンドで、-n(--dry-run)なら削除せず一覧だけ出します。-d はディレクトリも対象にし、-x は無視設定のファイルまで対象に含めます。公式ドキュメントには、削除後の復元可否の記述はありません。未追跡ファイルはGitが記録していないため、Gitから戻せるとは考えないでください。実行前に必ず git clean -nd で一覧を見ます。

AIに渡す確認依頼文

次の文は、そのままコピーして使えます。コマンドの案をAIが出してきた直後に貼ってください。

あなたが提案した次のgitコマンドを、実行前に確認したいです。
実行はせず、次の表の形で答えてください。

コマンド: (ここに貼る)

1. 消える・上書きされる物(未コミットの変更、未追跡ファイル、リモートの履歴を分けて)
2. 今の状態で影響を受けるもの。必要なら先に git status と git log --oneline -5 の出力を私に求めてください
3. 実行前の退避コマンド
4. 実行後に戻す手順と、戻せない物
5. もっと影響の小さい代替コマンドがあるか

分からない点は推測せず「不明」と書いてください。

AIに渡す情報は、git status --short と git log --oneline -5、対象のブランチ名で足ります。社内のリポジトリ名やファイル内容は、渡す前に架空の名前に置き換えると安全です。

実行直前の最終チェック

• 未コミットの変更は、コミットかstashで退避した。
• 現在位置に目印のブランチを作った。
• git clean は -n で一覧を見た。
• pushは、上書きされる側のSHAを控えた。
• --force ではなく --force-with-lease で足りるか確認した。
• 共有ブランチなら、チームの了承を得た。

AIの説明が上の表と食い違うときは、AIの説明ではなく公式ドキュメントを優先してください。表の内容もコマンドを手元で動かして検証したものではないので、重要なリポジトリでは、コピーしたフォルダなどで一度試してから本番に使うのが確実です。