The first way I'll show you to use the "git reset --hard" command imitates the way we used "git checkout" in the video Reverting to the Committed Versions of Files where we checked out the entire views directory.

Reseting Staged Files to the Latest Committed State

If you'd like to reset your uncommitted changes back to the last commit, you can use "git reset --hard" to do so. I'll demonstrate.

  • git reset --hard

Now, you'll see that "HEAD is now at 269bec4 Installed Views 3.8", so we're still at the same commit, and "git status" will show us that the only files not committed are the untracked files, just like when we ran "git checkout sites/all/modules/contrib/views" to checkout the entire views directory in the earlier video.

So, now, just like I did then, I'll delete the untracked file with the rm command.

  • rm -rf sites/all/modules/contrib/views/modules/field/views_handler_filter_field_list_boolean.inc

Now "git status" shows that we have a clean working directory and "git log --oneline" shows that we are at the "Installed Views 3.8" commit.

Resetting Multiple Commits and Associated Files

Now, we'll take a look at using the "git reset --hard" command, and passing a hash to reset multiple commits including associated files.

I'll start out by updating Views to 3.10 and committing it.

  • drush up views -y
  • git commit -am "Updated Views to 3.10"

Now a "git status" show us that we missed the unstaged file. I'll commit that now.

  • git add .
  • git commit -m "Added missing Views 3.10 file"

Now, "git status" shows a clean working directory, and "git log --oneline" shows the two commits. If, at this point, you realize that the 3.10 version of Views caused an issue and you'd like to reset those commits and associated files so that it'll be as though you never installed the update, you can do that by specifying the commit you would like to reset to.

* git reset --hard 269bec4

Now, you'll see that "HEAD is now at 269bec4 Installed Views 3.8", so our repo is back to the way it was before we updated Views.

Now, "git status" shows a clean working directory, and "git log --oneline" confirms that we are back to the "Installed Views 3.8" commit.

This is great, but what if you make a change and then make multiple commits before you realize that that change broke something? "git reset" isn't helpful, because you want to keep all of the changes since the bad commit. This is where "git revert" comes in. We'll take a look at how to use "git revert" in the next video.