Undo is an incomplete instruction

A coding agent changes a component, the preview breaks, and you ask it to undo the change. Meanwhile, you have edited copy in the same file and staged an unrelated configuration fix. Returning the entire repository to a previous commit would answer a different request.

Before choosing a command, name what must survive: the copy edit, the staged configuration change, existing commits and any untracked files. The target is the agent's unwanted change, not a clean-looking working directory.

This guide is for developers reviewing coding-agent repair plans. It proposes a small decision sheet that makes the affected Git state and the ownership of edits explicit.

Selection methodology: compare the affected state

We checked the official restore, reset and revert manuals on September 30, 2026. The comparison follows an invented mixed-edit scenario; we did not execute a rollback, test a third-party skill or recover a damaged repository.

The selection criteria are the intended result, affected paths, staging state, commit history and whether collaborators already use the commit. These matter more than which command is shortest.

Our earlier worktree and container guide addresses separation before work starts. This article addresses recovery when changes already coexist.

Restore changes selected file state

The restore manual distinguishes the working tree from the index. Without destination flags it restores working-tree content; staged restoration targets the index. Its default source also depends on those flags, so naming only the command does not specify the operation.

For a mistakenly staged file whose contents should remain, the review question is whether only staging should change. For an unwanted edit in a file, the question is which source version and which content should replace it.

Neither case means that every difference in that file belongs to the agent. When human and agent edits overlap, require a reviewed, selective patch rather than restoring the whole file. If ownership cannot be established, stop and show the ambiguity.

A path limit narrows the blast radius, but it does not identify authorship within the path.

Reset changes staging or the branch position

The reset manual documents both path-oriented index changes and commit-oriented operations that move HEAD. Modes determine whether the index and working tree also change. A hard reset can overwrite working-tree content, including untracked files in its way.

Our recommendation is therefore not a blanket ban on reset, but a requirement that an agent explain the exact form and consequence before proposing it. Unstaging a selected path and moving a branch backward are materially different actions.

In the example, a request to repair a component does not authorize discarding the user's staged configuration fix. A private-branch rewrite may be appropriate under a separate, explicit request, but should not be silently substituted for a narrow repair.

Do not treat a remembered commit hash as proof that the current checkout contains nothing worth preserving.

Revert records a new reversal

The revert manual describes recording new commits that reverse earlier changes. This makes it a useful candidate when a faulty commit has already been shared and the intended remedy is a visible follow-up in history.

It is not a guarantee that the resulting application is correct. Later changes may depend on the reverted behavior, and conflicts need review. Merge commits require a mainline decision and have implications for subsequent merges; they deserve a separate plan.

For the mixed-edit scenario, prepare the reversal in an appropriate clean working context without discarding unrelated local work. Do not solve a precondition failure by erasing changes.

Treat pushing the reversal and deploying it as distinct authorized steps. A local corrective commit is not evidence that production has changed.

Write a five-part repair request

Ask the agent to return these fields before a consequential undo:

Target: the exact unwanted behavior and the commit, paths or hunks believed responsible.
Preserve: existing user edits, staging choices, untracked work and shared history that must remain.
Operation: the proposed mechanism, source revision and affected Git state.
Review: the diff that will demonstrate the unwanted change was removed without expanding scope.
Verification: relevant application checks and the evidence to retain if they fail.

For our example, success means the component behavior is restored, the user's copy survives, and the configuration fix remains staged as intended. A clean status is neither required nor sufficient.

Start with read-only inspection of status, staged and unstaged diffs, and relevant history. If there is no trustworthy before-state for a mixed hunk, ask the owner rather than inferring which text is disposable.

Limitations and the handoff

Git inspection cannot recover every unsaved editor buffer, external database mutation or generated artifact. This workflow also does not guarantee recovery of discarded uncommitted data. Preserve work before destructive operations; do not promise that later recovery will be possible.

After the authorized repair, report the exact changes, remaining unrelated edits, checks actually run and any deployment still pending. If the repair fixes compilation but changes behavior, keep that distinction visible.

When choosing a coding workflow in the skill directory, look for this preservation contract. A useful agent should explain what it will keep before explaining how quickly it can undo the rest.