Choose a Git command by the change you need

Tool Last tested 26 October 2026

Choose a Git command by the change you need and the state your repository is in. This explorer pairs each command with its effect, a check of the result and a bounded undo explanation. It displays original, measured examples; it never reads a repository or runs a command for you.

Start with the state, not the verb

“Undo” can mean removing a local commit, unstaging a file, discarding an edit or reversing a change with a new commit. Those operations touch different parts of the repository. A command that preserves working files can still replace a carefully chosen staging selection. Git’s reset documentation distinguishes the commit, index and working-tree effects¹.

Choose the task first. Then choose the description that actually matches the repository. The example names, including note.txt and topic, are fictional. Read the command before adapting a filename or branch name. If none of the descriptions fits, leave the command alone and inspect the repository rather than choosing the nearest-looking label.

The explorer cannot establish whether a commit was shared, whether another person needs a branch or whether an untracked file has another copy. Those facts come from the project and the people working on it. A warning remains relevant even when the command itself is short.

Keep work while changing its place

These guides separate changes to history, staging and working files. Each includes a complete example that ran on Git 2.56.0 and walks through the resulting state.

• Undo a local commit while keeping edits compares staged and unstaged outcomes.
• Unstage a file without discarding edits changes the next commit’s contents while keeping the working file.
• Compare staged and working diffs shows why one file can have two different sets of changes.

An empty diff is an answer to a particular comparison, not proof that everything is unchanged. The diff reference defines the compared states². Check which comparison was requested before deciding that work has disappeared.

Move between tasks without guessing

Switching branches, creating a second working directory and saving edits in a stash solve different problems. Choose according to what should remain active and what should be set aside.

• Switch with unfinished work demonstrates a permitted switch and a refusal that protects edits.
• Use a linked worktree keeps a second task in its own working directory.
• Apply or pop a stash distinguishes a retained saved entry from one removed after success.

Keep the saved entry until its contents have been inspected when an extra copy matters. A successful command is not a substitute for reading the resulting files.

Handle a mistake with a specific recovery goal

• Abort a conflicted merge explains the clean-start case and its limits.
• Recover a recent local branch identifies a retained commit before creating a new branch reference.

Reflogs record local reference movements, but their entries and referenced objects are not permanent backups³. Recovery guidance should name what survives. It should not turn a successful synthetic example into a promise about expired records or edits that were never committed.

Inspect the evidence

The Git operation state matrix contains twenty independently initialized cases, their before-and-after observations and the scripts needed to reproduce them. Use it to inspect the conditions behind a statement, including which files and references changed. It measures this edition’s examples, not every repository configuration or operating system.

Not covered on this page

• Running commands, reading local repositories or uploading files.
• Recovering missing objects or work that was never saved.
• Choosing a workflow for an entire team.
• Comparing Git client products.