Right off the bat when working with Git, you run into these situations where you've committed some set of changes, and you realize that you forgot something, or you made a typo, or there was some bug you didn't think about, and you want to fix or amend it. How do you do that? I'll show you. Now, in this case, we'll assume it was a typo. We're going to make a commit with hello world, but because we're working fast, we didn't even see that we made a typo. Okay, we'll come back to that. Now, I will initialize Git.

Okay, we'll come back to that. Now, I will initialize Git. I'm starting from scratch again just to drill this workflow in. I list the files. I have one file here. Now, before, we were doing this, or we could say add all files to the staging area. Now, git status. There it is. So, we perform a commit with a message of whatever we just did, first draft of file. Remember, for a real project, be more descriptive of what you just did.

So, we perform a commit with a message of whatever we just did, first draft of file. Remember, for a real project, be more descriptive of what you just did. If you installed Laravel, then your message is install Laravel. Alright, so we git log, and we can see our commit. And don't forget about this unique hash or identifier. Think of that as an ID that points to this specific commit. So yeah, everything's going great, and then you're browsing your files in a few minutes, and you see crap. I made a mistake, or that wasn't quite right, or I forgot to add this. Now, the way you handle this depends upon context.

I made a mistake, or that wasn't quite right, or I forgot to add this. Now, the way you handle this depends upon context. Let's say that you've made your commit, and you've pushed it up to GitHub, or you've deployed it to your server, and we'll talk about all of that stuff in the future. But just imagine you've made your changes, and you've distributed them to GitHub and the other developers on your team. In those cases, the correct action would be to simply create a new commit. So in that case, you would say, fix the mistake, add it to the staging area, and commit it with fix-typo in this case. And that's a perfectly valid commit in this case.

with fix-typo in this case. And that's a perfectly valid commit in this case. git log, and now we have two commits. That would be one option. But what about if you're just working locally, you haven't shared this code with anyone just yet, and you found a mistake? Well, it's kind of a shame to have two commits, when really, all you meant to do was create that first commit. The second commit is fixing a mistake on your part that hasn't been shared with anyone. All right, in that case, here's what we're going to do.

The second commit is fixing a mistake on your part that hasn't been shared with anyone. All right, in that case, here's what we're going to do. I'm going to copy the original commit here, because I want to get rid of this. I sort of just want to force reset back to where I was before. So I will say, git reset, and we have two options here, a soft reset or a hard reset. A hard reset means reset everything to the way the code looked at this specific commit. Erase any changes I've made. So you want to be very careful with git reset. As a general rule of thumb, only ever refer to git reset if the changes you're making have never been shared with anyone else or pushed up to GitHub.

As a general rule of thumb, only ever refer to git reset if the changes you're making have never been shared with anyone else or pushed up to GitHub. Now if you were to say, git reset --soft, you would reset the commit, however, any changes you have made since then will still be reflected. That's why it's a soft reset. We're not getting rid of any code changes you've made currently, so we won't erase anything, but we will get rid of that commit. In our case, I want to reset totally. So we run it, and if I now run git log, we no longer see that commit. We're back to where we were at that time.

So we run it, and if I now run git log, we no longer see that commit. We're back to where we were at that time. And if I pull back sublime, sure enough, the typo is back. Okay, now we're going to review the other option, and really, the correct choice in this example. We have a commit that contains a typo, and I want to just amend that commit. That's all I want to do. Easy enough. Fix the mistake. That will show up on or in our staging area.

Fix the mistake. That will show up on or in our staging area. Remember, you don't always have to run git status. It's just a good general guideline so that you can keep an eye on what it is exactly you're committing. I'm going to go ahead and add this to the staging area, but this time, rather than creating a brand new commit, I want to instead amend the previous commit. We do that by saying git commit --amend. Now it pulls up vim for my machine. I can change the message if I want, or I can hit colon wq to exit out.

Now it pulls up vim for my machine. I can change the message if I want, or I can hit :wq to exit out. And that's it. I've fixed my changes. So now if I run git status, we don't see it there. If I run git log, we see the commit, but it now contains the correct hello world. And you can even inspect this. I will copy the commit and say git show, and this will show you the changes that were made. And sure enough, it says hello world spelled correctly.