AIが提案した「戻す」操作を選ぶ前に：restore・revert・resetを状況別に比較

先に押さえる3つの置き場所

Gitには、変更が存在する場所が3つあります。

1. 作業ツリー：エディタで編集して保存したファイルそのもの
2. インデックス（ステージ）：次のコミットに入れる内容として git add した状態
3. HEAD：いまのブランチの最新コミット

各コマンドは、このうちどこを動かすかで性質が決まります。なお、エディタで編集中でまだ保存していない内容はGitの管理外です。AIが「戻せます」と言っても、Gitではそこまで戻せません。保存前に戻したいときはエディタ側の元に戻す機能を使います。

状況別の判断表

下の表は、AIの提案を受けたときに「自分はどの行か」を探すためのものです。

• 保存済み・未ステージ、やりたいこと：1ファイルの変更を捨てたい、候補になる操作：git restore <ファイル>、履歴への影響：なし（ただし変更は失われる）
• git add 済み・未コミット、やりたいこと：ステージだけ外したい、候補になる操作：git restore --staged <ファイル>、履歴への影響：なし
• git add 済み・未コミット、やりたいこと：ステージも編集内容も捨てたい、候補になる操作：git restore --staged --worktree <ファイル>、履歴への影響：なし（変更は失われる）
• 過去のコミットの内容に1ファイルだけ戻したい、やりたいこと：他のファイルは触りたくない、候補になる操作：git restore --source=<コミット> <ファイル>、履歴への影響：なし（作業ツリーが上書きされる）
• コミット直後・まだpushしていない、やりたいこと：コミットだけ取り消し、変更は残したい、候補になる操作：git reset --soft HEAD~1（ステージも残す）または git reset HEAD~1（ステージは外す）、履歴への影響：ブランチが1つ前に戻る
• コミット直後・まだpushしていない、やりたいこと：コミットも変更も全部捨てたい、候補になる操作：git reset --hard HEAD~1、履歴への影響：ブランチが戻り、変更も失われる
• すでにpush済み・他の人が取得した可能性がある、やりたいこと：特定のコミットの効果を取り消したい、候補になる操作：git revert <コミット>、履歴への影響：取り消しの新コミットが増える

共有済みでも、他の人がそのコミットを取得していないなど、チームで合意して履歴を書き換える場合は運用ルールに従ってください。判断がつかなければ revert を候補にします。

公式ドキュメントでは、git revert は元のコミットを残して取り消しの新しいコミットを記録する操作です。一方 git reset --hard は、他者に渡したコミットに対して実行しないよう注意されています。共有済みの履歴をどう扱うかは、チームの運用ルールも確認してください。

消えるもの・残るものの一覧

git restore

• git restore a.js、作業ツリー：a.jsの未ステージ変更が消える（インデックスの内容に戻る）、インデックス：変化なし、コミット履歴：変化なし
• git restore --staged a.js、作業ツリー：残る、インデックス：HEADの内容に戻る（ステージが外れる）、コミット履歴：変化なし
• git restore -S -W a.js、作業ツリー：消える（HEADの内容に戻る）、インデックス：HEADの内容に戻る、コミット履歴：変化なし
• git restore --source=<コミット> a.js、作業ツリー：指定コミットの内容で上書きされる、インデックス：変化なし、コミット履歴：変化なし

指定しない場合の復元元は、--staged なしならインデックス、ありならHEADです。公式ドキュメントでは、作業ツリーの内容を指定した復元元に置き換えると説明されています。失いたくない変更がある場合は、実行前に差分を確認してください。

git reset

公式の挙動表を、AIの提案を読むための形にまとめます。

• --soft、HEAD（ブランチ位置）：指定先へ移動、インデックス：そのまま、作業ツリー：そのまま、典型的な意味：コミットだけ取り消す。変更はステージ済みで残る
• --mixed（省略時）、HEAD（ブランチ位置）：指定先へ移動、インデックス：指定先に合わせる、作業ツリー：そのまま、典型的な意味：コミットとステージを取り消す。ファイルの編集内容は残る
• --hard、HEAD（ブランチ位置）：指定先へ移動、インデックス：指定先に合わせる、作業ツリー：指定先に合わせる、典型的な意味：コミットも編集内容も捨てる

--merge と --keep もありますが、AIが提案してきたときは「作業ツリーの変更を守る目的の別モード」と理解した上で、状況をAIに説明させてから判断してください。

この表は追跡中のファイルを対象にしています。新規作成して一度もaddしていないファイルの扱いは、今回確認した資料の範囲では扱っていないため、実行前に git status で確認してください。

git revert

• git revert <コミット>、作業ツリー：取り消しの変更が反映される、インデックス：同上、コミット履歴：取り消しコミットが1つ追加される。元のコミットは残る
• git revert -n <コミット>、作業ツリー：取り消しの変更が反映される、インデックス：同上、コミット履歴：コミットは作られない（確認してから自分でコミットできる）
• git revert -m 1 <マージコミット>、作業ツリー：親1を基準に取り消す、インデックス：同上、コミット履歴：取り消しコミットが追加される

マージコミットは親が複数あるため、どの親を基準にするかを -m で指定します。親番号は1から始まります。AIが -m の番号を示したら、理由まで説明してもらってから実行してください。

実行前に人が確認する3点

AIに任せてよいのは、状況に合うコマンド候補の列挙と、各候補で何が失われるかの説明です。実行するかどうかは、次の3点を確認して人が決めます。

1. 共有済みか：git status の表示や、リモートへ push した記憶で確認します。共有後は revert を基本にします。
2. 捨てる変更が本当に不要か：restore と reset --hard は、作業ツリーの変更が失われます。迷うなら git diff > before-restore.patch のように差分をファイルに保存してから実行すると、後から内容を見返せます。
3. 対象の範囲：git restore . のように全体を指定する形は、AIが修正した他のファイルまで巻き込みます。ファイル名を明示した形に直してもらうと安全です。

reset の実行前には、現在のブランチの先端が ORIG_HEAD に保存されます。ただし、これは未コミットの編集内容を保護するものではありません。--hard で失う変更のバックアップにはならないため、必要な差分は別に保存してください。

AIに渡す依頼文の例

次の文面に、git status などの出力を貼ります。機密情報やトークンが含まれていないか、貼る前に確認し、必要なら説明用の名前に置き換えてください。

Gitで変更を戻したいです。実行はせず、次の順で答えてください。

【状況】
- やりたいこと：(例)直前のコミットの内容を取り消したい
- push済みか：(はい／いいえ／不明)
- 他の人が同じブランチを使っているか：(はい／いいえ／不明)

【git status の出力】
(ここに貼る)

【git log --oneline -5 の出力】
(ここに貼る)

【お願い】
1. 状況に合うコマンドを、restore / reset / revert から最大2案挙げる
2. 各案で「消えるもの」「残るもの」を、作業ツリー・ステージ・履歴に分けて書く
3. 実行前に私が確認すべきコマンドを書く
4. push済みの可能性がある場合は、履歴を書き換える案を出さない
5. 迷う点があれば、実行を勧めず質問する

返ってきた案は、上の「消えるもの・残るもの」の表と照らし合わせます。表と食い違うときは、実行せずAIに根拠を尋ねてください。

迷ったときの目安

• まだコミットしていない：restore を使う。ファイルを指定し、必要なら差分を保存する
• コミットしたが共有していない：reset を使う。変更を残すなら --soft か省略時の --mixed、捨てるなら --hard
• 共有した：revert を使う

--hard が登場したら一度止まり、「何が失われるか」をAIに言語化させてください。説明が曖昧なままなら、実行しないほうが安全です。