When to use mixed versus hard reset?

That's a fantastic question, and it gets to the core of understanding git reset! Choosing between --mixed and --hard depends entirely on what you want to achieve with your changes.

Let's use our current analogy of the "stack of boxes" (commits), the "preparation table" (staging area), and your "workspace floor" (working directory).

git reset --mixed (the default)

• How it works:

  • HEAD pointer moves: Git moves the HEAD sticky note to the specified commit (or keeps it on the current commit if you don't specify one).
  • Staging Area changes: Git clears the "preparation table" (staging area) and re-populates it to match the state of the new HEAD commit. This means any changes that were staged or uncommitted in the old HEAD's history are now considered "unstaged changes."
  • Working Directory remains UNCHANGED: The files on your "workspace floor" (working directory) are left exactly as they were. You don't lose any of your modifications.

• Analogy: You decide to go back a few boxes in your history. You move the HEAD sticky note. You sweep everything off your "preparation table" (staging area). But all the pieces you were working on are still on your "workspace floor" (working directory).

• When to use it:

  • You added files to the staging area by mistake (git add): This is the most common use case. You ran git add too early or included files you didn't mean to. git reset HEAD (or --mixed) will unstage them, returning them to your working directory as "unstaged changes."
  • You want to undo a commit, but keep all the changes as uncommitted files: Similar to --soft, but --mixed also unstages the changes, giving you a clean slate on your staging area. This is useful if you want to completely re-evaluate and re-stage how those changes should be committed.
  • You want to break down a large commit: You can git reset --mixed HEAD~1 (to undo the last commit) and then selectively git add -p different parts of the changes to create smaller, more focused commits.

• Safety: Very safe. You cannot lose any work from your working directory.

git reset --hard

• How it works:

  • HEAD pointer moves: Git moves the HEAD sticky note to the specified commit.
  • Staging Area changes: Git completely overwrites the "preparation table" (staging area) to match the state of the new HEAD commit.
  • Working Directory changes: Git completely overwrites the files on your "workspace floor" (working directory) to match the state of the new HEAD commit. All uncommitted changes will be lost.

• Analogy: You decide to go back a few boxes in your history. You move the HEAD sticky note. You sweep everything off your "preparation table." And crucially, you also scoop up everything off your "workspace floor" and throw it away, making your workspace floor perfectly match the state of the new HEAD commit.

• When to use it:

  • You want to completely discard all recent uncommitted changes AND undo recent commits: This is for when you've made a mess and just want to start fresh from an earlier, clean commit. For example, you tried out a feature that didn't work, and you want to completely erase it, both from your history and your current files.
  • You need to synchronize your local branch with a remote one: Sometimes, after pulling or fetching, you might want to force your local branch to exactly match the remote state, discarding any local modifications. You might use git fetch origin then git reset --hard origin/master (or your relevant branch).

• Safety: Dangerous! git reset --hard will permanently discard any uncommitted changes in your working directory and staging area. Only use it when you are absolutely sure you don't need those changes. You can sometimes recover lost commits using git reflog, but lost uncommitted changes are much harder, if not impossible, to get back.

Summary Table:

In general:

• Use git reset --mixed when you want to unstage files, or undo a commit but keep the code changes to rework them.
• Use git reset --hard when you are absolutely certain you want to discard everything (uncommitted changes and specified history) and revert to a specific commit.

Always think twice before using --hard! Hope this helps you choose the right reset for your situation!