What does Git reset change, and how can I understand its effects first?
Quick answer
For git reset with a commit argument, the mode determines which parts of your repository change: the branch reference, the staging area (index), and the working tree. --soft changes only the branch reference; the default --mixed also updates the index; --hard additionally makes working files match the index and can overwrite work. Inspect status and diffs first, and preserve changes you need. [S1][S2]
The question, the details, the next step.
I want to understand git reset before I run it. What does it actually change?
Think of a commit-level reset as potentially changing three layers: the current branch’s reference, the index (also called the staging area), and the working tree (the files in your checkout). Which layers change depends on the mode. [S1]
Here’s a plain-language effects table for git reset used with a commit argument:
--soft: Moves the branch reference to the selected commit. It does not reset the index or working tree.--mixed(the default): Moves the branch reference and updates the index to match the selected commit. It does not reset the working tree.--hard: Moves the branch reference, updates the index, and makes working files match the index. This can overwrite work. [S1]
This summary is not for every form of the command. Reset used with a path has different effects, so don’t apply it to a command such as git reset -- path. [S1]
How can I see what I have staged, what I changed but haven’t staged, and whether there are untracked files?
Start with git status. It distinguishes changes between HEAD and the index (staged changes) from changes between the index and working tree (unstaged changes), and reports untracked paths by default. [S2]
For more detail, git status --verbose can display staged and unstaged textual differences. [S2] Review the output and the relevant files to understand what you might need to preserve. Status is an inspection aid, not a backup, so separately preserve any changes you need before considering a reset. [S1][S2]
Could you show how the same situation might look with each mode, without implying I should run a reset?
Assume a placeholder repository has a current commit C, and you are considering a reset to an earlier commit P. Also assume you have both staged and unstaged edits. This is an illustration of commit-level reset, not a description of any particular repository.
- With
--soft, the branch reference moves fromCtoP, while the index and working tree are not reset by this mode. [S1] - With
--mixed, the branch reference moves toPand the index is updated to match that commit; the working tree is not reset by this mode. [S1] - With
--hard, the branch reference moves toP, the index is updated, and working files are made to match the index. This can overwrite work. [S1]
The broad effects don’t establish what a reset would do to your specific repository or which mode fits your goal. Your current status, target commit, and untracked files matter. If you’re unsure what you want preserved, pause rather than guessing.
Can I use a short pre-action routine to decide whether I understand the consequences?
Yes. Before any commit-level reset, write down the intended target commit and the exact mode you are considering. Compare that choice with the layers in the effects list: branch reference, index, and working tree. Inspect git status and, if useful, its verbose output; note untracked paths and review files you care about. Preserve needed work before proceeding. A clean-looking summary is not itself a backup, and this routine cannot guarantee that a command is appropriate for your situation. [S1][S2]
A practical checklist
Confirm whether the command uses a commit argument; path-based reset has different effects.
Write down the intended target commit and mode (
--soft,--mixed, or--hard).Run
git statusand note staged, unstaged, and untracked paths.Use verbose status output if you need to inspect staged and unstaged textual differences.
Preserve needed work separately before considering a reset, especially before
--hard.If you cannot explain which repository layers the chosen mode changes, pause and get help.
A few more useful answers
Is `--mixed` the same as `--hard`?
No. Both move the branch reference and update the index, but --hard additionally makes working files match the index and can overwrite work. [S1]
Does `git status` protect my changes?
No. It helps you inspect staged, unstaged, and untracked paths; it is not a backup. Preserve needed work separately. [S2]
Does this explanation cover `git reset -- path`?
No. The effects described here are for reset with a commit argument; path-based reset has different effects. [S1]
Sources
References used for this guide.
- [S1] Pro Git: Reset Demystified git-scm.com · Checked
- [S2] Git: git-status documentation git-scm.com · Checked