Understand reset before using it

When you reset a branch to a commit, Git moves the branch reference. The mode decides what happens to the index and working tree. Reset is powerful. I treat --hard as a last resort.

Work in notes-project on main. Before any reset, inspect and protect the current state:

git status
git log --oneline --decorate -5
git branch backup-before-reset

The backup branch gives the current commit a name. Recovery gets much easier when you have one.

A soft reset moves the branch but leaves the index and working tree unchanged:

git reset --soft HEAD~1

git status now shows the undone commit’s changes under Changes to be committed. The old commit’s changes appear staged.

The default mixed reset moves the branch and resets the index, but keeps working-tree files:

git reset HEAD~1

The changes now appear unstaged. git diff --staged is empty. git diff shows the file edits.

A hard reset moves the branch and makes both the index and tracked working files match the target:

git reset --hard HEAD~1

If you also had unstaged edits to notes.txt, they disappear from the working tree. Git does not keep a copy unless you committed or stashed them.

Panic fix: the reflog still records where HEAD was:

git reflog
git reset --hard backup-before-reset

You should land back on the commit the backup branch names. That is why I create a backup branch before experimenting.

If you already ran --hard without a backup, git reflog still lists recent HEAD positions. Find the entry before the reset and reset to that hash.

Reset is best kept to local history. If a commit is shared, prefer git revert so the correction becomes a normal new commit.

Try this in a disposable clone of notes-project: create backup-before-reset, run a soft reset, inspect status, then recover from the backup branch. Do not practice --hard with real work.