Use and Compare the Different git Reset Options: --hard, --soft, and --mixed

Chris Achard
InstructorChris Achard
Share this video with your friends

Social Share Links

Send Tweet
Published 4 years ago
Updated 3 years ago

git reset has three primary options that we might use: --soft, --hard and --mixed (the default).

We'll use git reset to undo the latest commit in all three ways, and compare the result of reseting with each flag.

Instructor: [0:00] If we take a look at git status, we have app.js which is not staged for commit. Let's open that and let's add those changes. We can do git add app.js and then git commit app jsChanges. If we do a git log oneline, we have this commit in our local tree. Let's explore the different ways we could reset this if we wanted to.

[0:26] We can do git --help reset and here's all the different options. The most common flags you'll see are soft, hard or mixed, which is the default. Let's look at each of those. First, we'll do a git reset --soft and we want to reset to back one from the HEAD. We'll do HEAD~1 to go back one.

[0:50] Once we do that, we can do a git status. We can see now that we have changes to be committed. What happened is we had changes that were committed and when we get reset --soft, that's like taking those changes and moving them back into the staging area. Nothing else changed. We just took our commit and moved it into the staging area.

[1:09] If we do a log oneline now, we don't have that commit anymore because we undid the commit. Let's redo that commit so we can try again. We'll do take two. Now if we do a git log oneline, then we have take two is our latest commit.

[1:25] Now let's git reset --mixed HEAD. We want to go back one again. This is the same as just saying git reset and then going back one, because mixed is the default. Now it says we have unstaged changes. Let's do a git status.

[1:41] Whereas before we had changes to be committed, these are changes not staged for commit. Mixed takes it back even one step further. It removes the commit, and then it unstages those changes. In app.js, our function is still there. We still have all the code. It just brought it all the way back to our working directory.

[2:01] Let's add app.js again. We'll commit it for take three. Now if we do a git log oneline, we have take three. Now we're about to do a git reset --hard but watch out because you almost never want to do this in real life, and you'll see why.

[2:22] Let's do git reset --hard. We want to HEAD~1, so going back one. We can see in our text editor, it got rid of that code. If we do a git status, we have nothing here except for our two commits which we had previously.

[2:39] What happened is, it got rid of the commit, it unstaged the changes, and then also removed them from our working directory. We lost the work that we did. We lost that function. That's why you usually don't want to do a git reset --hard.

egghead
egghead
~ an hour ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today