Undo And Recovery

git reset moves the current branch and HEAD to another commit. By itself, reset does not create a new commit like git revert does. Instead, it rewrites your local branch position, which is why it is usually safe only on private local history.

The second part of reset is the mode. --soft keeps changes staged, --mixed unstages them but keeps the file edits, and --hard rewrites both the index and working tree to match the target commit. If you do not specify a mode, git reset means git reset --mixed.

Use a specific commit hash when you want to name the exact commit that HEAD and the branch should move to. The reset mode still decides what happens to your staged and unstaged local changes afterward.

Use a relative reference like HEAD~1 when you want to move back from the current commit by position instead of naming a hash directly. The reset mode still decides what happens to your staged and unstaged local changes afterward.

git revert does not move a branch backward. Instead, Git reads an existing commit, calculates the opposite change, and writes a brand new commit that undoes it. That keeps history linear and auditable, which is why revert is usually the right choice on shared or protected branches.

git restore writes file content back into your working tree or staging index without creating a new commit. Use plain git restore to discard a local file edit, or git restore --staged to remove a file from the next commit snapshot while leaving the working copy alone.

Fast environment recovery can be handled by your deployment automation tool or CI/CD release platform. Git history correction should still be PR-governed.

git reflog shows where HEAD and your branch references used to point, even after reset, checkout, or accidental branch moves. If a commit seems lost locally, reflog is often the fastest way to find that older pointer and create a recovery branch before Git garbage collects unreachable objects.