Join Kevin Skoglund for an in-depth discussion in this video Demonstrating a mixed reset, part of Git Essential Training.
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.
- Exploring the history of version control
- Installing Git on Mac, Windows, and Linux
- Initializing a repository
- Writing useful commit messages
- Understanding the Git three-tree architecture
- Tracking when files are added, edited, deleted, or moved
- Viewing change sets and comparing versions
- Undoing changes and rolling back to previous versions
- Ignoring changes to select files
- Creating and working with code branches
- Merging branches and resolving merge conflicts
- Stashing changes for later
- Working with hosted repositories and remote branches
- Developing an effective collaboration workflow
Skill Level Beginner
Q: In the Chapter 10 movie "Configuring the command prompt to show the branch," when I type the function "__git_ps1," I do not get the expected result.
A: The function "__git_ps1" was recently moved to a new file, .git-prompt.sh, as described here: https://github.com/git/git/commit/af31a456b4cd38f2630ed8e556e23954f806a3cc.
We will update the video. In the meantime, you may do the same steps you do for .git-completion.bash, but a second time using ".git-prompt.sh" as shown here: https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh.
Q: When I use the code the instructor advises in the above video ("git config --global user.name "Nelda Street"), I still get an "Illegal Instruction" error. I have OS 10.6.8. Am I doing something wrong?
A: The current installer version of git isn't compatible with older Mac OS versions.
1. To add "-mmacosx-version-min=10.6" as described here:https://stackoverflow.com/questions/14268887/what-is-the-illegal-instruction-4-error-and-why-does-mmacosx-version-min-10https://stackoverflow.com/questions/10177038/illegal-instruction-4-shows-up-in-os-x-lion
2. Or to use the version of git that comes with Xcode, or to use homebrew to install git instead.http://superuser.com/questions/697144/installed-git-not-sure-how-to-get-it-working