Introduction

If a commit has not been pushed, you can safely rewrite local history to remove or adjust it. The correct command depends on whether you want to keep the changes in your working tree, keep them staged, or discard them completely. Choosing the right reset mode avoids accidental data loss and keeps your local branch clean.

Core Sections

Inspect current state before rewriting history

Before changing commit history, inspect branch status and recent commit graph. This gives a recovery point and avoids operating on the wrong branch.

git status
git log --oneline --decorate -n 5

If needed, create a temporary backup branch before reset:

git branch backup/pre-reset

This backup is cheap insurance when you are unsure which reset mode to use.

Remove last commit but keep changes staged

Use soft reset when commit message or commit grouping is wrong and you want to recommit quickly.

git reset --soft HEAD~1
git status

--soft moves branch pointer back one commit and keeps all previous commit changes staged.

Remove last commit and unstage changes

Use mixed reset when you want to edit files before recommitting.

git reset --mixed HEAD~1
git status

This keeps file modifications in working tree but unstages them. It is the default reset mode.

Remove last commit and discard changes

Use hard reset only when you intentionally want to delete both commit and local modifications.

git reset --hard HEAD~1
git log --oneline -n 3

This is destructive. Confirm backup or reflog recovery path before running.

Recover from mistakes with reflog

If you reset incorrectly, reflog usually lets you recover local commit references.

git reflog -n 10
git reset --hard HEAD@{1}

Reflog is one of the most useful safety tools for local history edits.

Remove older local commits with interactive rebase

If the commit to remove is not the latest, interactive rebase is the standard approach.

git rebase -i HEAD~4

In the opened list, replace pick with drop for the commit you want removed, then save and continue. Use this only on unpushed local history to avoid breaking collaborators.

Use amend when only small fix is needed

If you only need to edit the most recent commit message or add one forgotten file, amend is cleaner than reset and re-commit.

git add forgotten-file.txt
git commit --amend

This replaces the last commit with an updated one.

Keep local history edits auditable in team workflows

Even for unpushed commits, it helps to leave clear terminal history in pull request descriptions when major local rewrites were done. Briefly noting reset or rebase actions can prevent confusion during review when commit hashes changed between branch updates.

For complex cleanups, prefer creating a fresh branch from a known commit and cherry-picking desired changes. This gives a clean audit trail and reduces accidental carryover from experimental commits.

When mentoring newer contributors, teach reset modes with a disposable practice repository. Hands-on practice prevents risky mistakes on active feature branches.

Common Pitfalls

• Using --hard reset when you only intended to edit commit content.
• Rewriting commits on a shared branch after they were pushed.
• Resetting from the wrong branch without checking status and log.
• Forgetting reflog exists and assuming data is unrecoverable.
• Using rebase without understanding which commits are included in range.

Summary

• Choose reset mode based on whether changes should be staged, unstaged, or discarded.
• Use git reset --soft for fast recommits and --mixed for editing.
• Reserve --hard for intentional destructive rollback only.
• Use reflog to recover from incorrect local history edits.
• Prefer amend or interactive rebase when fixing commit structure rather than deleting blindly.