VS CodeでGitをResetする方法｜(neo) Git GraphとCodexのAGENTS.mdを解説

なぜ(neo) Git Graphを使うのか

結論からいうと、履歴上の戻りたいコミットを選び、Resetの種類を指定して操作するためです。VS Code標準機能との違いを整理します。

VS Code標準機能でできること

VS Codeのソース管理には、変更の確認、ステージ、コミット、履歴表示など、普段のGit作業に必要な機能があります。「Undo Last Commit」を使えば、最後のコミットを取り消し、変更をステージ済みで残すこともできます。

標準のグラフではResetを選びにくい

標準機能の「最後のコミットを取り消す」は便利ですが、数個前のコミットへ戻りたい場合や、Soft・Mixed・Hardを選びたい場合には不足します。ターミナルからgit resetを実行できますが、コミットIDとオプションを正しく指定する必要があります。

グラフから戻りたい場所を選べる

(neo) Git Graphでは、コミット履歴を見ながら対象を選択し、右クリックメニューからResetを実行できます。コミット件名、日時、変更ファイルも同じ画面で確認できるため、戻り先を判断しやすくなります。

GitのResetとは？

Resetは、現在のブランチが指している位置を、指定したコミットへ移動するGitの操作です。単に画面表示を過去へ切り替えるのではなく、コミット履歴、ステージ、作業ファイルの状態へ影響します。

ブランチの現在位置を過去へ戻す

Gitでは、現在のコミットをHEADという目印で表します。Resetを実行すると、HEADと現在のブランチが指定したコミットへ移動します。その後にあるコミットは、現在のブランチ履歴から外れます。

削除したいコミットではなく戻りたいコミットを選ぶ

履歴がA → B → Cの順で、現在位置がCだとします。Cの変更を取り消してBの状態へ戻したい場合は、Bを選んでResetします。Cを選ぶのではない点が重要です。

A ── B ── C  ← 現在
     ↑
  Bの状態へ戻るなら、Bを選んでReset

Resetする前に未コミット変更を確認する

Resetの前にVS Codeの「ソース管理」またはgit statusで未コミット変更を確認します。特にHard Resetでは作業ファイルも戻るため、残したい変更がある場合は先にコミットするか、Stashで一時保存します。

Resetの3種類を理解する

Soft・Mixed・Hardは、すべてブランチ位置を指定したコミットへ戻します。違うのは、取り消したコミットの変更をステージと作業ファイルへ残すかどうかです。

Soft Reset：変更をステージ済みで残す

Soft Resetはコミット履歴だけを戻し、取り消したコミットの変更をステージ済みの状態で残します。ファイル内容は変わりません。コミット件名を直したいとき、複数のコミットをまとめ直したいとき、ファイルを少し追加して再コミットしたいときに向いています。

git reset --soft <戻りたいコミット>

実行後は、VS Codeのソース管理で対象ファイルが「ステージされている変更」に表示されます。そのまま新しいコミットメッセージを付けて、コミットし直せます。

Mixed Reset：変更を未ステージで残す

Mixed Resetはコミット履歴を戻し、ステージも取り消しますが、ファイルの変更内容は残します。取り消した変更を1ファイルずつ確認したい場合、不要な部分を修正したい場合、コミットを分け直したい場合に使いやすい方法です。

git reset --mixed <戻りたいコミット>

実行後は、対象ファイルが「変更」に表示されます。差分を確認し、必要なファイルだけを改めてステージしてからコミットします。迷ったときは、変更内容が残るMixedの方が確認しやすい場合があります。

Hard Reset：変更内容も含めて戻す

Hard Resetはコミット履歴、ステージ、作業ファイルをすべて指定したコミットの状態へ戻します。取り消したコミットの変更を残す必要がないときに使います。

git reset --hard <戻りたいコミット>

Hard Resetは未コミットの変更も失う可能性があります。実行前に差分を確認し、必要な変更をコミットまたはStashへ保存してください。また、すでに共有リポジトリへPushしたコミットは、履歴を書き換えるResetを安易に使わず、変更を打ち消す新しいコミットを作るRevertも検討します。

(neo) Git GraphでResetする手順

仕組みを理解したら、グラフ上で戻りたい状態を選びます。操作前後にソース管理の表示を確認すると、選んだResetの結果を判断できます。

1．未コミットの変更を確認する

VS Code左側の「ソース管理」を開き、「変更」にファイルが残っていないか確認します。残っている場合は、Resetで一緒に扱ってよい変更かを判断します。Hardを使う場合は、必要な変更を必ず退避します。

2．戻りたい状態のコミットを選ぶ

VS Code下部の「(neo) Git Graph」を開きます。コミット件名と変更ファイルを確認し、戻りたい状態を表すコミットを右クリックします。取り消したいコミットではなく、その1つ前などの「残したい最後の状態」を選びます。

3．Resetの種類を選ぶ

メニューから現在のブランチを選択したコミットへResetする操作を選び、目的に合わせてSoft・Mixed・Hardを指定します。再コミットするならSoft、内容を見直すならMixed、変更ごと不要ならHardが基本です。

4．Reset後の状態を確認する

グラフで現在のブランチ位置を確認し、ソース管理でステージ済み・未ステージ・変更なしのどれになったかを確認します。想定と違う場合は、そのままコミットせず、Resetの種類と戻り先を見直します。

Codexで修正からコミットまで進める

Resetで安全な状態へ戻した後は、Codexへ修正内容を具体的に依頼し、差分を確認してからコミットします。Codexへコミットを依頼する場合も、何を変更したかを人が確認する流れは同じです。

1．変更内容を具体的に依頼する

対象、目的、期待する表示を短く伝えます。たとえば「ヘッダーの子カテゴリーを、デスクトップではできるだけ1行で表示してください」のように依頼します。必要なファイルを先に決められなくても、Codexがプロジェクトを調べて対象を特定できます。

2．変更結果と差分を確認する

Codexの完了報告と、VS Codeのソース管理に表示された変更ファイルを確認します。Webサイトなら実際の表示、PHPなら構文、CSSなら対象画面幅など、変更内容に合った確認を行います。

3．Codexへコミットを依頼する

内容に問題がなければ、同じタスクで「コミットしてください」と依頼します。Codexはプロジェクトのルールを確認し、対象ファイル、差分、動作確認に沿ったコミットメッセージでコミットします。

変更内容を確認しました。プロジェクトのGitルールに従ってコミットしてください。

4．グラフでコミットを確認する

Codexから報告されたコミットハッシュと件名を確認し、(neo) Git Graphを更新します。最新コミットをクリックし、対象ファイルと差分が意図した内容だけになっていれば完了です。

AGENTS.mdへGitルールを書く

AGENTS.mdは、Codexがプロジェクトで作業するときに読む指示ファイルです。Gitの確認手順やコミットメッセージの方針を書いておけば、毎回同じ説明を繰り返さずに済みます。

新しいタスクでもルールが適用される

Codexは作業開始時にAGENTS.mdの指示を読みます。プロジェクト直下のAGENTS.mdへ書いたルールは、同じプロジェクトで開始した新しいタスクでも適用されます。現在進行中のタスクへ確実に反映したい場合は、ファイルを保存してから新しいタスクを開始します。

ファイル名は複数形のAGENTS.md

ファイル名はAGENT.mdではなく、末尾にSが付くAGENTS.mdです。プロジェクト全体へ共通ルールを適用する場合は、通常はGitリポジトリの一番上に置きます。

Gitルールの記述例

次のように、いつコミットするか、何を確認するか、完了時に何を報告するかを簡潔に書きます。プロジェクトに必要な項目だけへ絞ると、Codexが判断しやすくなります。

# Git作業ルール
- ユーザーから依頼された場合のみコミットする。
- コミット前に対象ファイルと差分を確認する。
- 1つのコミットには原則として1つの目的だけを含める。
- コミット件名は変更目的が分かる具体的な日本語にする。
- 必要に応じて対象ファイル、変更内容、影響範囲、動作確認を本文へ書く。
- 完了時にコミットハッシュと件名を報告する。
- 未コミットの変更が残る場合は、その内容を報告する。

ルールを置いた後の流れ

AGENTS.mdを保存したら、新しいCodexタスクで通常どおり修正を依頼します。作業が終わった後に「コミットしてください」と伝えるだけで、Codexは同じプロジェクトのGitルールを確認してコミットを進めます。

まとめ