Git Reset Cheat Sheet: Soft vs. Hard (With Examples)

Understanding git reset is crucial for any developer using Git for version control. This command allows you to undo changes, but it’s powerful and potentially destructive if not used correctly. This cheat sheet provides a comprehensive guide to git reset, focusing on the difference between soft and hard resets, and providing practical examples to help you confidently manage your Git repository.

Table of Contents

1. What is Git Reset?
2. Understanding Git’s Areas: Working Directory, Index (Staging Area), HEAD
3. Different Types of Git Reset
   1. Git Reset –Soft
   2. Git Reset –Mixed (Default)
   3. Git Reset –Hard
4. Practical Examples
   1. Example 1: Undoing the Last Commit (Soft Reset)
   2. Example 2: Undoing Staging Changes (Mixed Reset)
   3. Example 3: Discarding Local Changes (Hard Reset)
   4. Example 4: Resetting to a Specific Commit
   5. Example 5: Resetting Multiple Commits
5. Git Reset vs. Git Revert
6. How to Recover from an Accidental Reset
7. Best Practices for Using Git Reset
8. Common Mistakes to Avoid
9. Conclusion

1. What is Git Reset?

git reset is a powerful command in Git that allows you to move the current branch’s HEAD to a specific commit. It essentially rewrites the commit history of your local repository. The key distinction lies in how it affects the different areas of your Git workflow: the commit history (HEAD), the staging area (index), and your working directory.

Understanding the different options (--soft, --mixed, and --hard) is essential because they determine which of these areas are affected, and therefore, the potential data loss. Using git reset incorrectly can lead to lost work, so proceed with caution.

2. Understanding Git’s Areas: Working Directory, Index (Staging Area), HEAD

To fully grasp git reset, it’s important to understand the three main areas in a Git repository:

1. Working Directory: This is where you directly edit your files. It represents the current state of your project on your local machine.
2. Index (Staging Area): This area is a snapshot of the content of the working directory that you want to include in your next commit. You add files to the staging area using git add.
3. HEAD: This is a pointer to the most recent commit on the current branch. It essentially represents the “tip” of your branch. The HEAD pointer is moved by commands like git commit, git checkout, git merge, and, of course, git reset.

Visualize these areas as distinct stages in the process of creating a commit:

1. You make changes to files in your Working Directory.
2. You git add the changes to the Index (Staging Area).
3. You git commit the staged changes, which moves the HEAD pointer forward, creating a new commit in your history.

git reset allows you to manipulate these areas, moving the HEAD pointer and potentially affecting the Index and Working Directory.

3. Different Types of Git Reset

The power of git reset comes from its options: --soft, --mixed, and --hard. Each option affects the HEAD, Index, and Working Directory differently.

3.1 Git Reset –Soft

The --soft reset is the least destructive option. It only affects the HEAD. It moves the HEAD to the specified commit, but it leaves the Index (staging area) and the Working Directory untouched. This means your changes are still staged and ready to be committed.

• HEAD: Moves to the specified commit.
• Index (Staging Area): Unchanged.
• Working Directory: Unchanged.

When to use it:

• When you want to undo the last commit but keep the changes for further editing or to create a new, more refined commit.
• When you committed changes with the wrong commit message and want to amend the commit with a better message.

Example:

git reset --soft HEAD~1

This command moves the HEAD back one commit (HEAD~1), but leaves all the changes from that commit staged and ready for a new commit.

3.2 Git Reset –Mixed (Default)

The --mixed reset is the default behavior of git reset if no option is specified. It affects both the HEAD and the Index. It moves the HEAD to the specified commit and unstages the changes. However, it leaves the Working Directory untouched. This means your changes are still present in your working directory, but they are no longer staged.

• HEAD: Moves to the specified commit.
• Index (Staging Area): Reset to match the specified commit (unstaged).
• Working Directory: Unchanged.

When to use it:

• When you want to undo the last commit and unstage the changes, but keep the changes in your working directory to modify or discard them later.
• When you accidentally added files to the staging area that you don’t want to commit.

Example:

git reset HEAD~1

This command moves the HEAD back one commit and unstages all the changes from that commit. Your files will still be present in your working directory, but you’ll need to git add them again to stage them for a new commit.

3.3 Git Reset –Hard

The --hard reset is the most destructive option. It affects the HEAD, the Index, and the Working Directory. It moves the HEAD to the specified commit and completely discards any changes in the Index and Working Directory that are not present in that commit. This means you will permanently lose any uncommitted changes.

• HEAD: Moves to the specified commit.
• Index (Staging Area): Reset to match the specified commit.
• Working Directory: Reset to match the specified commit. Warning: This will discard uncommitted changes!

When to use it:

• When you want to completely discard local changes and revert your working directory and staging area to a previous state.
• When you’ve made a mistake and want to start over from a known good commit.
• When you are absolutely sure you no longer need the changes you’ve made since the specified commit.

Example:

git reset --hard HEAD~1

This command moves the HEAD back one commit and discards all changes in your staging area and working directory that were made since that commit. Use this command with extreme caution!

WARNING: git reset --hard can lead to data loss. Double-check that you’ve committed or stashed any important changes before using it. If you accidentally run it, see the “How to Recover from an Accidental Reset” section below.

4. Practical Examples

Let’s walk through some practical examples to illustrate how git reset works in different scenarios.

4.1 Example 1: Undoing the Last Commit (Soft Reset)

Suppose you’ve made a commit with the following message: “Fix: Resolved issue #123”. However, you realize that you forgot to include a crucial change in that commit. You can use a soft reset to undo the commit and add the missing change.

1. Check the current status:

   git status
   

   You’ll see that your working directory is clean, and you’re on the latest commit.

2. Perform a soft reset:

   git reset --soft HEAD~1
   

   This moves the HEAD back one commit, but keeps the changes staged.

3. Check the status again:

   git status
   

   You’ll see that the changes are staged (“Changes to be committed”).

4. Make the missing change:

   Edit the file(s) where you missed the change.

5. Stage the updated changes:

   git add .
   

6. Commit the changes with a new message (or amend the original):

   git commit -m "Fix: Resolved issue #123 (with missing change)"
   

   Or, to amend the previous commit:

   git commit --amend -m "Fix: Resolved issue #123 (with missing change)"
   

4.2 Example 2: Undoing Staging Changes (Mixed Reset)

Imagine you’ve accidentally staged some files that you don’t want to include in your next commit. A mixed reset is the perfect solution.

1. Check the current status:

   git status
   

   You’ll see the files you accidentally staged under “Changes to be committed”.

2. Perform a mixed reset:

   git reset HEAD
   

   This unstages all the changes.

3. Check the status again:

   git status
   

   You’ll see the files listed under “Changes not staged for commit” as modified.

4. Now you can selectively stage the files you *do* want to commit:

   git add  
   

5. Commit the changes:

   git commit -m "Your commit message"
   

4.3 Example 3: Discarding Local Changes (Hard Reset)

Let’s say you’ve been experimenting with some new features in your working directory, but you’ve decided to scrap them and revert to the last committed state. A hard reset will clean everything up.

WARNING: This will permanently delete your uncommitted changes. Make sure you don’t need them before proceeding. Consider using git stash to save your changes temporarily instead.

1. Check the current status:

   git status
   

   You’ll see the modified files listed under “Changes not staged for commit” or “Untracked files”.

2. Perform a hard reset:

   git reset --hard HEAD
   

   This discards all uncommitted changes and resets your working directory to the last commit.

3. Check the status again:

   git status
   

   You should see “nothing to commit, working tree clean”.

4.4 Example 4: Resetting to a Specific Commit

Sometimes you need to revert to a specific commit in your history, not just the previous one. You can do this by providing the commit hash to git reset.

1. View your commit history:

   git log --oneline
   

   This will display a concise history of your commits, including their commit hashes (the long string of hexadecimal characters).

2. Identify the commit you want to revert to. For example, let’s say the commit hash is a1b2c3d4e5f67890.
3. Choose the reset type you want to use:
   • Soft: Keeps changes staged.
   • Mixed: Unstages changes (default).
   • Hard: Discards changes.
4. Perform the reset:

   git reset -- a1b2c3d4e5f67890
   

   Replace with soft, mixed, or hard, depending on your needs.

   For example, to perform a hard reset:

   git reset --hard a1b2c3d4e5f67890
   

4.5 Example 5: Resetting Multiple Commits

You can reset multiple commits by using the ~ (tilde) notation or specifying a commit hash. For example, HEAD~3 refers to the commit that is three commits before the current HEAD.

1. View your commit history:

   git log --oneline
   

   This will display a concise history of your commits, including their commit hashes (the long string of hexadecimal characters).

2. Determine how many commits you want to undo, or the specific commit hash to revert to.
3. Choose the reset type you want to use:
   • Soft: Keeps changes staged.
   • Mixed: Unstages changes (default).
   • Hard: Discards changes.
4. Perform the reset:

   Using the ~ notation:

   git reset -- HEAD~3
   

   Replace with soft, mixed, or hard, depending on your needs. This will reset the last 3 commits.

   Using a commit hash:

   git reset -- a1b2c3d4e5f67890
   

   Replace with soft, mixed, or hard, depending on your needs. This will reset to the commit with hash a1b2c3d4e5f67890.

5. Git Reset vs. Git Revert

Both git reset and git revert are used to undo changes, but they operate in fundamentally different ways.

• git reset: Modifies the commit history by moving the HEAD pointer. It can be destructive, especially with the --hard option. It’s primarily used for undoing changes on your local branch.
• git revert: Creates a new commit that undoes the changes introduced by a specific commit. It doesn’t modify the existing history; instead, it adds a new commit that represents the opposite of the reverted commit. This is the safer option for undoing changes on a shared branch, as it doesn’t rewrite history that others may have already based their work on.

Here’s a table summarizing the key differences:

• Rewrites History: git reset: Yes (potentially). git revert: No
• Data Loss: git reset --hard: Yes. git revert: No
• Impact on Shared Branches: git reset: Should be avoided. git revert: Safe.
• Creates New Commit: git reset: No. git revert: Yes
• Intended Use: git reset: Local changes, cleaning up mistakes. git revert: Undoing changes on shared branches.

In short: Use git revert on shared branches and git reset on local branches when you’re cleaning up mistakes and haven’t pushed your changes yet.

6. How to Recover from an Accidental Reset

Accidentally running git reset --hard is a common fear, but thankfully, Git has a mechanism to help you recover: the reflog.

The reflog (reference log) keeps a record of all the changes to the HEAD pointer, even if those changes aren’t part of a branch. This means you can use the reflog to find the commit that you accidentally reset to and restore your lost changes.

1. View the reflog:

   git reflog
   

   This will display a list of recent actions that have modified the HEAD pointer, along with a short description of each action and a corresponding commit hash.

2. Identify the commit before the reset:

   Look for the entry in the reflog that represents the state of your branch *before* you ran the git reset command. The description will likely say something like “reset: moving to HEAD~1” or “reset: moving to “. Note the commit hash associated with that entry.

3. Create a new branch or reset to the commit:

   To create a new branch:

   git checkout -b recover-branch 
   

   This creates a new branch named recover-branch that points to the commit you identified in the reflog. You can then examine the changes in that branch and merge them back into your main branch if desired.

   Alternatively, to reset directly (use with caution):

   git reset --hard 
   

   This will reset your current branch to the specified commit. This will overwrite your current working directory and staging area, so make sure you understand what you’re doing!

Example:

Let’s say your reflog looks like this:

a1b2c3d HEAD@{0}: reset: moving to HEAD~1
  d4e5f6g HEAD@{1}: commit: Added new feature
  h7i8j9k HEAD@{2}: commit: Fixed bug

You accidentally ran git reset --hard HEAD~1. To recover, you can see that d4e5f6g is the commit before the reset. You can then create a new branch or reset to that commit:

git checkout -b recover-branch d4e5f6g

7. Best Practices for Using Git Reset

To minimize the risk of data loss and ensure a smooth Git workflow, follow these best practices when using git reset:

• Understand the different options: Know the difference between --soft, --mixed, and --hard, and choose the appropriate option for your needs.
• Commit frequently: Regular commits provide a safety net in case you need to undo changes.
• Stash changes: If you’re not ready to commit changes but want to experiment, use git stash to temporarily save your work.
• Use git reset on local branches only: Avoid using git reset on shared branches, as it can rewrite history and cause problems for other developers. Use git revert instead.
• Double-check your command: Before running git reset, especially with the --hard option, carefully review the command and the potential consequences.
• Use git status frequently: Keep track of the state of your working directory and staging area to avoid surprises.
• Learn to use the reflog: Familiarize yourself with the reflog and how it can be used to recover from accidental resets.

8. Common Mistakes to Avoid

Here are some common mistakes to avoid when using git reset:

• Using git reset --hard without understanding the consequences: This is the most common mistake and can lead to significant data loss. Always double-check before using --hard.
• Using git reset on a shared branch: This can rewrite history and cause problems for other developers who are working on the same branch. Use git revert instead.
• Forgetting to commit or stash changes before running git reset --hard: This will permanently discard any uncommitted changes.
• Not using the reflog to recover from accidental resets: The reflog is a powerful tool that can help you recover from mistakes.
• Being unsure of the current state of your repository: Always use git status to check the state of your working directory and staging area before running git reset.

9. Conclusion

git reset is a powerful and versatile command that can be used to undo changes in your Git repository. By understanding the different options (--soft, --mixed, and --hard) and following best practices, you can use git reset effectively and safely. Remember to exercise caution, especially with the --hard option, and always use the reflog to recover from accidental resets. With practice and a solid understanding of the concepts presented in this cheat sheet, you’ll be able to confidently manage your Git repository and streamline your development workflow.