How to Use git reset to Revert to Previous Commit in Git

Have you committed too early, included the wrong files, or taken a local branch in a direction you no longer want? Git Reset to Previous Commit lets you move that branch back to an earlier commit using git reset. The difficult part isn’t typing the command. It’s choosing what should happen to the changes that came after the target commit.

This guide shows how to use git reset to revert to a previous commit while protecting the work you may still need. It is written for developers who are comfortable running basic Git commands but want a safer way to undo local commits. You’ll learn how Git’s three reset modes behave, practice them in a disposable repository, handle common scenarios, and recover when a reset goes farther than intended.

Quick safety rule: If the commits are already on a shared remote branch, pause before using git reset. In most team workflows, git revert is the safer choice because it preserves the published history.

TL;DR

• Use git reset --soft HEAD~1 to remove the latest commit while keeping its changes staged.
• Use git reset HEAD~1 to remove the latest commit while keeping its changes unstaged. This is the default --mixed behavior.
• Use git reset --hard HEAD~1 only when you intentionally want to discard tracked changes as well as commits.
• Inspect git status, git log, and git diff before and after resetting.
• Prefer git revert for commits that teammates may already have pulled.
• If you reset to the wrong place, use git reflog to locate the earlier branch position.

Before You Reset: Decide Whether History May Be Rewritten

The key question to ask first is not, “Which reset mode is right for me?” It is “Does anyone else depend on this branch history?”

git reset changes where the current branch points. A commit can disappear from the visible path of that branch even though Git may retain the underlying object for some time.

That is convenient on a private feature branch. On a shared branch such as main, however, rewriting the published sequence can leave another developer’s local history out of sync.

Use this decision table before running anything:

Git’s official documentation separates these jobs clearly: git reset moves a branch or updates the index, while git revert records a new commit that reverses an earlier commit.

If your team deploys from Git, history changes can also affect the commit a server expects to fetch. Review the deployment pipeline before rewriting any branch used in production.

Understand What git reset Actually Changes

A Git project has three working layers that matter during a reset:

• HEAD and the current branch: HEAD normally refers to the branch you have checked out, and that branch points to a commit.
• The index: Also called the staging area, it stores the snapshot prepared for the next commit.
• The working tree: These are the files you can currently open and edit.

When you run:

git reset <target-commit>

Git moves the current branch to . The mode determines whether Git also changes the index and working tree.

If no mode is supplied, Git uses --mixed.

Two details prevent common surprises:

• --hard can overwrite modifications to tracked files. Commit, stash, or back up anything you may need first.
• A hard reset does not generally remove ordinary untracked files. Removing untracked files is a separate operation, commonly handled with git clean, which is outside the reset itself.

There are additional options such as --merge and --keep, but they solve narrower cases involving local changes and merge-like resets.

For the everyday task of returning a private branch to an earlier commit, soft, mixed, and hard are the modes worth understanding first.

Read Full Article: https://serveravatar.com/git-reset