Git gives you several ways to undo changes, but knowing which one to use can be confusing.

You might need to revert a single commit, restore a previous version, or completely reset your repository to an earlier state. Each command handles this differently.

This guide explains how git reset works, how it differs from git revert and git restore, and when to use each. It also walks you through the steps to safely return your repository to a previous commit using git reset.

Understanding Git Reset

Git reset is a versatile command that moves your current branch pointer to a different commit.

This action can:

  • Undo recent changes or remove specific commits.
  • Adjust what’s staged for your next commit.
  • Update your working directory to match an earlier point in your project’s history.

Because it can rewrite history, understanding how each reset mode behaves is critical before using it.

Suggested read: GitHub vs. GitLab vs. Bitbucket – How Are They Different? 

Types of Git Reset

Git provides several reset modes, each suited to different needs:

1. --soft

Moves HEAD to a specific commit but leaves both the staging area and working directory unchanged.

  • Useful for undoing a commit while keeping all changes staged.
  • Example: git reset --soft HEAD~1

2. --mixed (default)

Resets the index but not the working directory. Changes remain unstaged but intact.

  • Example: git reset --mixed HEAD~1

3. --hard

Resets both the index and working directory to match a commit, discarding all uncommitted changes.

  • Example: git reset --hard HEAD~1

4. --merge

Updates files in the index and working tree that differ between HEAD and the target commit, keeping local changes that aren’t staged.

  • Example: git reset --merge HEAD~1

5. --keep

Similar to --merge, but aborts if local changes would be lost.

  • Example: git reset --keep HEAD~1

6. --recurse-submodules

Resets submodules alongside the main project to ensure consistent versions.

  • Example: git reset --recurse-submodules HEAD~1

Suggested read: Laravel With GIT Deployment The Right Way

Git Reset vs Revert vs Restore

Git provides several ways to undo or modify changes, but each command serves a distinct purpose.

The table below highlights the differences between git reset, git revert, git restore, and git checkout, helping you choose the safest command for your situation.

Git ResetGit RevertGit RestoreGit Checkout
Primary Use CaseMove a branch back in time, effectively erasing commits from the local branch history.Create a new commit that reverses the changes from a previous commit.Discard uncommitted changes to files in your working directory or staging area.Switch branches or view files from a different commit/branch.
Impact on HistoryRewrites branch history. The original commits are no longer on that branch.Preserves branch history. It adds a new commit to the timeline.No impact on history. Only affects uncommitted changes.No impact on history. It’s a read-only command that just moves your HEAD pointer.
Safety on Shared Branches (e.g., main)🔴 UNSAFE. Rewriting history on a shared branch will cause major conflicts for your collaborators.SAFE. This is the standard, team-friendly way to undo changes on a shared branch.SAFE. It only affects your local, uncommitted work.SAFE. It’s a fundamental navigation command.
Scope of ChangeAffects commits, the staging area, and the working directory (depending on the mode: --soft, --mixed, --hard).Affects commits. It creates a new commit that changes files.Affects files in the staging area and/or the working directory.Affects the entire working directory by changing the HEAD pointer to a new branch or commit.
Common Syntaxgit reset --hard <commit>
git reset <commit>
git reset --soft <commit>
git revert <commit>git restore <file>
git restore --staged <file>
git checkout <branch-name>
git checkout <commit> -- <file> (legacy file restore)

Suggested read: The Easiest Way To Automate WordPress Deployments with Git

How to Reset to a Previous Commit

Follow these detailed steps to perform a Git reset and restore your project to a previous commit:

Step 1: Find the Target Commit Hash with git log

First, you need to find the commit hash of the point you want to reset to. Open your terminal or command prompt, navigate to your Git repository, and use the following command to view your commit history:

git log
git log status

This command will display a list of commits, each with a unique hash, author information, date, and commit message.

Alternatively, you can view this commit history in your Git provider’s dashboard. Scroll through the list and find the commit you want to reset to. Note down the commit hash, which is a long string of letters and numbers.

git commit history

Step 2: Choose the Correct Reset Mode

Git offers several reset modes, each with different effects on your working directory and staging area (see previous section).

Choose the mode that fits your goal. In this example, a mixed reset (the default) is used to unstage changes while keeping them in your working directory for review.

Step 3: Execute the git reset Command

Now that you’ve identified the commit and chosen the reset type, you can perform the reset. Use the following command, replacing <commit-hash> with the hash you noted earlier:

git reset <commit-hash>
git reset to revert changes

This command will move your branch pointer to the specified commit and update your staging area. Your working directory will remain unchanged, allowing you to review the changes before committing them again.

Step 4: Review the changes

After performing the reset, it’s important to review the changes. Use the following command to see the status of your working directory:

git status
git status

This will show you which files have been modified, added, or deleted since the commit you reset to. You can also use git diff to see the specific changes in each file.

Step 5: Commit the changes

Once you have reverted the changes, you can make modifications and edits to the files as you normally would.

If you’re satisfied with the reset and any restorations you’ve made, you can now commit these changes. First, add the files you want to include in the commit:

git add .
git commit -m "Reverted to previous state and restored specific files"
Git add and commit

Step 7: Push the changes (if working with a remote repository)

If you’re working with a remote repository and want to update it with your reset changes, you’ll need to force push. Be cautious with this step, as it can overwrite the remote history:

git push --force origin <branch-name>

Replace <branch-name> with the name of your current branch (e.g., main or master).

Suggested read: Understanding Continuous Integration vs. Continuous Deployment

Final Thoughts

Mastering Git reset gives you precise control over your project’s history — allowing you to cleanly adjust commits, recover from mistakes, and prepare your repository for deployment.

RunCloud takes that same precision into production with Atomic Deployments.

When you deploy through RunCloud, each release is packaged and deployed as a single, complete unit. If anything goes wrong, RunCloud automatically falls back to the previous version in seconds, protecting uptime and data integrity.

RunCloud atomic deployment

Combining Git proficiency with RunCloud’s Atomic Deployment system creates a seamless, reliable workflow: commit confidently, deploy instantly, and roll back safely whenever needed.

Start your free RunCloud trial today and bring the best of Git and server automation together in one platform.

Frequently Asked Questions About Git Reset

Does git reset delete new files?

No, git reset does not delete new files. It only affects tracked files and the staging area, leaving untracked files untouched.

What is the difference between git reset and git restore?

git reset moves your branch pointer and can modify commit history, the staging area, or both, depending on the reset mode used.
git restore only affects files in your working directory or staging area. It restores file content to match a specific commit without changing the repository history.

What is the difference between git reset and git reset hard?

git reset can be used in several modes (–soft, –mixed, or –hard), each controlling how much of your work is reset.
git reset –hard is the most destructive option as it resets your branch, staging area, and working directory to match the target commit, permanently discarding all uncommitted changes in tracked files.

Is git reset local or remote?

git reset is a local operation. It only affects your local repository and does not modify the remote branch until you push changes.
To overwrite the remote history after a reset, you would need to use git push –force, but this should be done with caution on shared branches.

Does git reset restore deleted files?

Yes. If a deleted file was tracked by Git, running git reset to a commit where that file existed will restore it.
However, untracked files deleted outside of Git cannot be recovered this way.

What does git reset file do?

git reset removes the specified file from the staging area (the index) but leaves your working directory unchanged.
This is useful if you accidentally added a file with git add and want to unstage it before committing.

Will git reset remove local changes?

Yes, but only when using the –hard option.
git reset --hard resets both your working directory and staging area to match the specified commit, permanently removing all uncommitted changes in tracked files.
Using git reset without –hard (e.g., –soft or –mixed) will leave your working directory changes intact.

Can I undo a git reset?

Yes. You can recover from a reset using git reflog.
Run git reflog to view recent branch movements and find the commit reference for the state you want to restore.
Then reset back to it using:
git reset --hard <commit-hash>

Can I use git reset to remove commits from a remote repository?

By default, git reset only affects your local branch.
If you’ve already pushed those commits to a remote, you’ll need to force-push to update the remote branch:
git push --force origin <branch-name>
Use this with care, as it rewrites history for anyone else working on the same branch.