Introduction

If the commits are still local and have not been pushed anywhere, deleting them is usually just a matter of moving the branch pointer backward. The right command depends on whether you want to discard the changes completely or keep them in your working tree for more editing. The most important safeguard is to verify that the commits are truly unpushed before you rewrite history.

Confirm That the Commits Are Local Only

Start by checking the recent history and branch state:

git log --oneline --decorate -n 10
git status
git branch -vv

If the commits have not been pushed, you can rewrite the local branch safely. If they were already pushed to a shared remote, deleting them becomes a coordination problem rather than a simple cleanup.

Remove the Last Commit Completely

If you want to delete the last local commit and discard its changes, reset the branch one commit backward:

git reset --hard HEAD~1

For two commits:

git reset --hard HEAD~2

This moves the branch and resets the index and working tree to match the new HEAD. It is the fastest cleanup option, but it also discards the file changes from those commits.

Remove the Commit but Keep the Changes

If you want to delete the commit history but keep the changes for editing or recommitting, use a softer reset.

Keep changes staged:

git reset --soft HEAD~1

Keep changes unstaged:

git reset HEAD~1

These are often better than --hard when the commit message or commit boundaries were wrong, but the actual code changes are still useful.

Delete Several Unpushed Commits

The same idea applies when you want to remove multiple local commits:

git reset --hard HEAD~3

or, if you want to keep the file changes:

git reset --soft HEAD~3

The number after HEAD~ is simply how many commits to move back.

When Interactive Rebase Is Better

If you want to drop some commits but keep others, interactive rebase is often the cleaner tool:

git rebase -i HEAD~4

That opens a list of the last four commits. You can mark selected commits to drop, reorder them, or squash them instead of deleting everything in one reset.

Use this when the history cleanup is selective rather than "remove the last N commits."

Recovering If You Reset Too Far

Even if you make a mistake, Git often still knows where the old HEAD was through the reflog:

git reflog

You can usually recover by resetting back to an earlier reflog entry. That safety net is one reason local history rewriting is less scary than it first appears.

Common Pitfalls

One common mistake is using git reset --hard when the file changes were still needed. If you want to keep the edits, use --soft or the default mixed reset instead.

Another mistake is assuming the commits are unpushed without checking. Rewriting already-pushed shared history is a different and riskier operation.

Developers also sometimes use reset when they really need interactive rebase. If only some commits should disappear, rebase gives finer control.

Finally, do not forget reflog exists. If a local reset went wrong, recovery is often still possible.

Summary

• Use git reset --hard HEAD~N to delete unpushed commits and discard their changes.
• Use git reset --soft HEAD~N or mixed reset if you want to keep the changes locally.
• Check first that the commits are truly unpushed.
• Use interactive rebase when you want to remove only selected commits.
• If you make a mistake, git reflog often lets you recover the old branch state.