AIにファイルを編集させる前に覚えたいGitの「元に戻す」：作業のやり直しの基本

※この記事にはアフィリエイト広告（PR）が含まれています。

この記事でわかること

• コミット直後に内容やメッセージを直す手順
• ステージしたファイルだけを取り下げる方法
• 作業ディレクトリの変更を消す操作と、その危険性
• git statusを使った安全な切り分けと判断

AIにファイルを編集させる前に覚えたいGitの「元に戻す」は、作業を自動化するときの保険になります。AIが編集したファイルをそのまま採用するのではなく、変更を確認してからコミットし、必要なら段階ごとに戻せる状態を作るためです。

ただし、Gitの「戻す」操作は一種類ではありません。コミットを直したいのか、ステージングエリアから外したいのか、ファイルの変更そのものを捨てたいのかで、使うコマンドと危険度が変わります。ここを混同すると、残したかった編集まで消してしまいます。

まずは現在地を確認する

作業のやり直しで最初に見るコマンドは git status です。Gitの公式ドキュメントでは、状態を表示するだけでなく、ステージングエリアや作業ディレクトリの変更を取り消す方法も同時に表示されると説明されています。

たとえば、ふたつのファイルを別々のコミットにするつもりで編集したのに、誤って git add * を実行したとします。この時点では両方のファイルがステージされています。出力には次のような案内が表示されます。

Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

ここで決めるのは「編集内容を消すか」ではなく、「コミット対象から外すだけか」です。編集は残しておきたいなら、ステージ解除を選びます。逆に、変更そのものが不要なら、作業ディレクトリの変更を破棄する操作が候補になります。

この判断を飛ばしてコマンドを打つのが、つまずきやすい原因です。AIの編集結果を確認中なら、まず git status の表示を読み、Changes to be committed と Changes not staged for commit のどちらにファイルがあるかを切り分けます。

コミットを直す手順：--amend

よくある例は、コミットを早まりすぎて追加すべきファイルを忘れたケースと、コミットメッセージが変になったケースです。この場合は、直近のコミットを --amend オプション付きでやり直します。

git commit --amend

このコマンドは、ステージングエリアの内容をコミットに使用します。直近のコミット以降に何も変更していなければ、スナップショットの内容はまったく同じで、コミットメッセージを変更する操作になります。エディタには前回のメッセージが書かれた状態で表示され、通常どおり編集できます。

ファイルを入れ忘れた例では、次の流れです。

git commit -m 'initial commit'
git add forgotten_file
git commit --amend

最終的にできあがるのはひとつのコミットです。二番目のコミットが、最初のコミットの結果を上書きします。ここでのポイントは、git add していないファイルは --amend の対象にならないことです。AIが複数ファイルを編集した場合も、追加したいファイルだけをステージしてから実行するのが無難です。

なお、共有済みのコミットをどう扱うかや、リモート上の履歴への影響については、この資料の範囲では扱われていません。少なくとも、直近のコミットをローカルで整える操作として理解しておくと、目的を取り違えにくくなります。

ステージだけを解除する：git reset HEAD <file>

編集は残し、コミット対象からだけ外したい場合は、ファイルを指定して次のコマンドを使います。

git reset HEAD CONTRIBUTING.md

実行後には、次のような表示になります。

Unstaged changes after reset: M CONTRIBUTING.md

その後に git status を実行すると、別のファイルは Changes to be committed に残り、CONTRIBUTING.md は Changes not staged for commit に移ります。つまり、ファイルの編集内容は消えず、ステージングエリアから外れただけです。

git reset は危険なコマンドになりえます。特に --hard オプションを付ける場合が該当します。一方、ここで扱っているオプションなしの git reset は、ステージングエリアの状態だけを変更し、作業ディレクトリのファイルには変更を加えていません。

AIの出力をファイルへ反映したあと、変更の一部だけを採用したい場面では、この違いが役立ちます。たとえば、READMEの変更はコミット対象に残し、設定ファイルの変更はもう少し見直す、といった分け方です。

ファイルの変更そのものを取り消す：git checkout -- <file>

作業ディレクトリにある変更が不要だと判断した場合、資料では次の方法が示されています。

git checkout -- CONTRIBUTING.md
git status

実行すると、直近のコミット時点の状態、あるいは最初にクローンしたり最初に作業ディレクトリへ取得したときの状態に戻ります。先ほどの例では、CONTRIBUTING.md の変更が消え、ステージ済みの README.md の変更だけが残ります。

ここは、ステージ解除との違いを表で整理すると判断しやすくなります。

目的	操作	編集内容への影響
コミットを直す	git commit --amend	ステージングエリアの内容で直近のコミットを上書きする
ステージだけ外す	git reset HEAD <file>	作業ディレクトリの編集は残る
ファイルの編集を捨てる	git checkout -- <file>	ファイルへの変更がすべて消える

git checkout -- [file] は危険なコマンドです。ファイルに加えた変更はすべて消え、変更後の内容を別のファイルで上書きしたのと同じ状態になります。そのファイルが不要だと確実に判断できる場合以外は、実行を急がないほうがよいでしょう。

編集を残したまま一時的に横へ置きたいなら、資料では stash やブランチを調べる方法が示されています。ここで扱う事実は、そうした方法の詳細ではなく、「消す」のではなく一時退避する選択肢もある、という点です。AIの編集内容に迷いがあるなら、破棄より退避を優先する判断が向いています。

復旧できる変更と、失うと戻せない変更

Gitにコミットした内容は、ほぼ常に取り消しが可能です。削除したブランチへのコミットや、--amend コミットで上書きされた元のコミットでさえも復旧できます。資料では、データの復元方法については「データリカバリ」で扱うと案内されています。

一方、まだコミットしていない内容を失ってしまうと、それは二度と取り戻せません。ここが、AI編集との組み合わせで特に気を付けたい線引きです。AIが生成した差分を保存する前に破棄コマンドを実行すると、後から同じ内容を戻せるとは限りません。

実務では、次のような確認順が扱いやすいでしょう。

1. git status で、ファイルがコミット済みか、ステージ済みか、未ステージかを見る。
2. コミットを直すなら、必要なファイルを git add してから git commit --amend を使う。
3. ステージだけ外すなら、対象ファイルを指定して git reset HEAD <file> を実行する。
4. 編集を捨てるなら、内容が不要だと判断できた場合だけ git checkout -- <file> を使う。
5. 迷うなら、破棄せず stash やブランチによる一時退避を検討する。

この手順なら、「コミットを修正したかったのにファイルを消した」「コミット対象から外したかっただけなのに編集まで失った」という切り分けミスを減らせます。

まとめ

• git status は、現在の状態と取り消し方法を確認する入口です。
• 直近のコミット修正は git commit --amend、ステージ解除は git reset HEAD <file> を使い分けます。
• git checkout -- <file> は未コミットの編集をすべて消すため、実行前の判断が欠かせません。
• コミット済みの内容は復旧できる場合がありますが、未コミットの内容を失うと戻せない点に注意が必要です。

この記事に関連するアイテム：退屈なことはPythonにやらせよう 第3版