Introduction

Discarding local commits in Git means moving your branch pointer back to an earlier commit. The right command depends on whether you want to keep the file changes in your working tree, keep them staged, or throw them away completely.

The key safety rule is to inspect the branch before resetting it. git reset is powerful, and the difference between --soft, --mixed, and --hard is not cosmetic.

Check What You Are About To Remove

Before changing history, confirm which commits are local and where you want the branch to end up.

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

If the branch tracks a remote, it is also useful to compare with that remote tip:

git fetch origin
git log --oneline --decorate HEAD..origin/main
git log --oneline --decorate origin/main..HEAD

That prevents the classic mistake of counting back from HEAD~N incorrectly.

Remove The Commits But Keep The Changes

If the commits are wrong but the code changes should stay, reset without destroying the working tree.

Keep the changes staged:

git reset --soft HEAD~2

Keep the changes but unstage them:

git reset --mixed HEAD~2

Both commands move the branch back two commits. The difference is whether the content remains staged in the index. This is useful when you want to recommit the work with better messages or a different commit split.

Remove The Commits And The Changes

If you want to discard the commits and all associated file modifications, use a hard reset:

git reset --hard HEAD~2

This makes the branch, index, and working tree match the target commit exactly. It is destructive to uncommitted and committed local work on that branch tip, so only use it when you are sure you want that outcome.

Reset Directly To The Remote Branch

A very common request is not "remove the last two commits" but "make my branch look exactly like the remote again." In that case, resetting to the remote-tracking branch is clearer than counting commits:

git fetch origin
git reset --hard origin/main

This is often the safest way to abandon all local commits on a local branch that tracks origin/main.

Know When reflog Can Save You

Git usually records previous branch-tip positions in the reflog. If you reset to the wrong place, you can often recover quickly:

git reflog

Then reset back to the earlier position:

git reset --hard HEAD@{1}

This does not make reckless resets safe, but it is one of the most useful recovery tools when you realize the mistake immediately.

Local Commits Versus Pushed Commits

The title says local commits, and that distinction matters. Reset is safest when the commits exist only in your local repository. If you already pushed those commits to a shared branch, discarding them with reset rewrites published history. In that case, the workflow changes:

• coordinate a force-push if rewriting shared history is acceptable
• or use git revert if public history should remain intact

That is why "local" is the important qualifier in this question.

Common Pitfalls

One common mistake is using git reset --hard when the real goal was only to remove commit history while keeping the code changes. Another is forgetting to fetch before resetting to a remote-tracking branch, which means you may reset to stale remote information. Developers also sometimes discard the wrong number of commits with HEAD~N because they did not inspect the log first. Finally, people often assume discarded commits are gone forever when git reflog could still recover them.

Summary

• Use git reset to discard local commits by moving the branch pointer backward.
• Choose --soft, --mixed, or --hard based on whether you want to keep the file changes.
• Reset to origin/branch when the real goal is to match the remote exactly.
• Check git reflog if you reset to the wrong place.
• Use extra caution if the commits were already pushed, because that changes the problem from local cleanup to history rewriting.