Claude Codeの変更を1ファイルだけ戻す｜git add済みの修正を残す手順
Claude Codeの変更を1ファイルだけ戻し、git add済みの修正を残すなら、Gitの復元元は「ステージ」です。最後のコミットとは限りません。まず作業を止め、下の2種類の差分で、残す修正がどちらにあるか確かめてください。
著者：ノオ · Git操作確認：2026年10月21日
最初は、変更しない次の3行だけ。 プロジェクトのフォルダーで実行します。settings.txtは例なので、実際に戻したいファイルのパスに置き換えてください。
git status --short
git diff -- settings.txt
git diff --cached -- settings.txt2行目は「まだgit addしていない差分」、3行目は「git add済みで、まだコミットしていない差分」です。残したい変更が2行目にもあるなら、このあと紹介するファイル全体の復元は止めてください。 同じファイルの不要な変更と一緒に消えてしまいます。
画像はAIで制作した説明用イメージです。Claude Codeの操作画面や検証時の写真ではありません。
「元の状態」は3か所にある
設定ファイルを暗い表示へ直してgit addしたあと、別の変更で値が壊れたとします。暗い表示への修正は残したい場面です。
検証用のsettings.txtを、次の状態にしました。
| 保存されている場所 | 今回の内容 | 意味 |
|---|---|---|
| HEAD（最後のコミット） | theme=light | 前回確定した状態 |
| ステージ（index） | theme=dark | git addで選んだ、残したい修正 |
| 作業中のファイル | theme=broken | 後から入り、取り消したい変更 |
git status --shortの結果は次のとおりでした。別ファイルのnotes.txtはGitに追加していないメモです。
MM settings.txt
?? notes.txtこの例のMMは、ステージと作業ファイルの両方に変更がある印です。git diff -- settings.txtではdarkからbrokenへの変更が、git diff --cached -- settings.txtではlightからdarkへの変更が出ました。
「Gitで元に戻す」とだけ考えると、残したいdarkまでlightに戻してしまいます。 今回の目的なら、戻り先は真ん中のステージです。表示の詳しい意味はGitのstatus公式説明、2種類の比較はdiff公式説明でも確認できます。
add済みの修正を残して、後の変更だけ取り消す
Claude Codeやエディタの書き込みを止め、対象ファイルをプロジェクト外へコピーします。未保存の編集も別名で保存し、退避先で開けることを確認してください。
ここからはGitが追跡している通常の1ファイルが対象です。残したい内容がステージにあり、作業ファイルとステージの差分をすべて捨ててよいと確認できた場合に限り、次を実行します。改行末尾のバックスラッシュは、macOSのシェルで命令を次の行へ続ける記号です。
git restore --worktree \
-- settings.txt検証では、作業ファイルはtheme=darkになりました。ステージもtheme=darkのままです。git diff -- settings.txtの差分はなくなり、git diff --cached -- settings.txtには暗い表示への修正が残りました。
M settings.txt
?? notes.txtMの右側が空いたのは、作業ファイルがステージと一致したためです。表示にMが残っていても、取り消しの失敗ではありません。 残したかった変更が、コミット前の状態で待っています。対象に指定していないnotes.txtの内容も変わりませんでした。
Gitは編集者を区別しません。残す行と捨てる行が同じ未追加の差分に混ざっている場合は、退避したコピーと照合し、必要な行だけ手作業で直します。
最後のコミットへ戻したい場合は、結果が違う
同じ初期状態に戻して、復元先を変える3通りを確認しました。いずれも対象はsettings.txtだけです。
| 選びたい結果 | 作業ファイルの結果 | ステージの結果 |
|---|---|---|
| A：add済みの修正を残す | theme=dark | theme=dark |
| B：ファイルだけ前回コミットへ戻す | theme=light | theme=dark |
| C：add済みの修正も取り消す | theme=light | theme=light |
Aは前の節のコマンドです。3つを順番に実行する手順ではありません。目的に合うものを1つ選びます。
Bは、ファイルの中身だけを最後のコミットに戻します。
git restore --source=HEAD \
--worktree -- settings.txtこの場合、ステージにはdarkが残りました。検証のgit status --shortは再びMMです。ファイルを開くとlightでも、そのままステージ済みの内容をコミットするとdarkが入るため、見た目だけで完了と判断しないでください。
Cは、対象ファイルについてステージも作業ファイルも最後のコミットへ戻します。add済みの修正も不要だと決めた場合だけ使います。
git restore --source=HEAD \
--staged --worktree \
-- settings.txt検証では両方がlightになり、settings.txtの変更表示は消えました。別の未追加ファイルnotes.txtは残りました。
Gitのrestore公式説明では、復元元を省略した場合と--sourceで指定した場合、作業ファイルとステージのどちらを変えるかが分けられています。今回の3例でも、その違いを確認できました。
/rewindを選ぶのは、会話の時点へ戻したいとき
複数の編集を、ある指示を出す前の状態へまとめて戻したいなら、Claude Codeの/rewindが候補になります。入力欄が空ならEscを2回押してもメニューが開きます。戻す時点を選び、コードだけか、会話も戻すかを確認します。
ただし、Bashコマンド経由のファイル変更はチェックポイントで追跡されません。「会話が戻ったからファイルも戻った」とは判断せず、結果を確認してください。詳細はClaude Codeのチェックポイント公式説明にあります。
Gitで戻しても会話履歴は変わりません。再開時は「このファイルをGitで戻したので、現在の内容を読み直してから続けて」と伝えます。
実測したのはGitの復元です。/rewindは公式資料での確認で、メニュー操作を実験した記録ではありません。
戻り先が見つからない場合
??の新規ファイル、競合、Git管理外のフォルダーは今回の対象外です。保存されていない過去の内容を、この操作で作り出すことはできません。コピーやエディタの履歴、該当するチェックポイントを探してください。
コミット済み・共有済みの変更や、削除ファイルの救出も別の作業です。対象を.に広げたり、reset --hardやcleanへ置き換えたりしないでください。
操作後は冒頭の3行を再実行し、残す差分と消す差分を照合します。アプリの設定やコードは、画面やテストでも動作を確認してから次へ進みます。
確認環境：2026年10月21日、macOS、Git 2.50.1（Apple Git-155）。検証用リポジトリの通常のテキストファイルで確認。Windows、競合、サブモジュール、リンクされたファイル、本番データ復旧は未検証です。