Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
The course shows how to use Git, the popular open-source version control software, to manage changes to source code and text files. Using a step-by-step approach, author Kevin Skoglund presents the commands that enable efficient code management and reveals the fundamental concepts behind version control systems and the Git architecture. Discover how to track changes to files in a repository, review previous edits, and compare versions of a file; create branches to test new ideas without altering the main project; and merge those changes into the project if they work out. The course begins by demonstrating version control in a single-user, standalone context, before exploring how remote repositories allow users to collaborate on projects effectively.
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.
Find answers to the most frequently asked questions about Git Essential Training.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.