In the last movie we saw that the soft reset moved the HEAD pointer but didn't
do anything else. It left our staging index and our working directory alone.
Now we're going to look at a mixed reset.
Mixed reset works exactly the same as the soft reset with one additional
thing, which is that it makes the staging index look the same as what's in the repository.
So as I noted in the last movie, it's always a good idea when you're working
with resets to just grab those last few commits, copy them, and paste them into
a new document, so we have them to refer to if we need to get back here later.
Let's make the same commit, let's go back to the same point in time, but this
time let's use a mixed reset instead of the soft reset.
We're not going to look at the actual file for refs/heads/master, we did that
in the previous movie, we know that the HEAD pointer moves in each of these cases now.
So let's copy this, and let's do git reset --mixed, and then our new SHA, that's going to reference it.
Git reset -mixed, it comes up afterwards, and it says unstaged changes after
reset, that's what it normally tells us when we unstage something.
So let's take a look, git status, and you can see changes not staged for
commit, meaning changes that are in my working directory includes modifications to resources.html.
So if we do git diff, we can see what those changes are, and we can see that
it is our reversion, where we moved sunglasses, sunscreen, insect repellent,
back down to the bottom.
So again, it did the exact same thing as git soft did, the only difference here
is how our staging index looks.
The changes that we had subsequently made are not gone, they're just only in our working directory.
They're not in two places, they're just in one place.
So it's almost as safe as the soft reset, because we do still have these changes here.
They're ready for us to restage them and then recommit them.
Now, we can also just take a look at the log real quick to see that in fact it
did roll us back to this commit, and so that's where it will start recording new
commits going forward. We've essentially just undone that commit.
So if you find that you've made two or three commits, and then you think, you know what?
I wish I could just go back and redo those commits again, this is
what does it for you. It allows you to rewind back, let's say, three commits,
all of those changes are still in your working directory, now you can go and
make those commits over again.
Now, the one thing that I did want to point out to you about reset is that if I
do git add all, you can see that I've got the file in my staging directory.
Notice that the command here is a reset command. That is what it's asking us to
do if we want to unstage things.
Git reset from the HEAD so that's the commit that it's using, wherever the
HEAD is pointing now--instead of using the SHA, it's using HEAD--and then tell
it which file, we're not telling it to move the pointer and then make our
staging directory look the same, we're telling it just to go get the file that
is where the HEAD is at.
So the HEAD doesn't move, the HEAD stays in exactly the same place that it's in
now, but it also then pulls down just this one file from the HEAD to make the
staging directory match it.
So that's another instance where we're using git reset that might not be
immediately obvious that it's doing the exact same thing.
So there it is, stage changes after reset, we've got it back in our working
directory just like we did when we moved the HEAD pointer and made our staging
directory look the same.
So doing a git reset is the same thing as doing git reset mixed.
Now just like before, because we haven't recorded anymore commits yet, that old
commit is still there, and we can actually go back to it again.
Let's just do that real quick, and let's do git reset, and we want to still make
sure we do a mixed one so that we get our staging directory to look the same,
git reset and mixed back to that future version, status no changes, and git log
and our reversion is back again.