In the last video, we installed Git and created our first commit. Let's go through that process again. We initialize Git. We add a file to the staging area. You can use a period for all files, or you can be explicit. And then you commit it, and give it a message of, in this case, first commit, or anything descriptive of what change you just made. Alright. Now, if I run git log, sure enough, we've created our first commit, and we have this unique identifier, as well as who created it, and the date of the commit.

Now, if I run git log, sure enough, we've created our first commit, and we have this unique identifier, as well as who created it, and the date of the commit. But now, if you're anything like me, you understand that basic workflow, but you don't exactly know what each part does. You just know that it works. So, for example, what exactly happens when I say git add? Or what happens when I commit it? That very much confused me in the early days. So let's start from scratch and talk about that a bit more. I will remove, with recursive force, the git directory.

So let's start from scratch and talk about that a bit more. I will remove, with recursive force, the git directory. And that will essentially remove any representation of Git for this project. So now, for example, if I run git log, it'll say, hey, there's no Git repository here. Okay. So it will start again. Initialize Git. You only do that once per project. Now we have a Git repo. Next, we add a file to the staging area.

Now we have a Git repo. Next, we add a file to the staging area. We're imagining that we've been working on this piece of code for a while, and we're ready to commit it. So I say git add index.html. Add this file to the staging area. Here's how I like to think of it. We take a photo of the current state of the file, its contents, and we set it on the truck to be sent off to the warehouse. But that truck has not yet taken off.

And those files never get saved or tracked under version control. That's what git commit does. Think of that as saying, okay, I put all my snapshots on the truck. We're ready to go. Go ahead and get to the warehouse and lock these away. git commit with a message, first commit. However, there's another key thing to understand here. Imagine that we run git add. And you know what? Let's just do it again from scratch.

And you know what? Let's just do it again from scratch. git init git add index.txt. Okay, so we've added it to the staging area. And if I run git status, sure enough, it's represented there. Now, what if before the truck takes off, we change the contents of that file? Let me show you. Let's open this up in Sublime, in my case. And let's just say hello world 2. Some change to the code base.

And let's just say hello world 2. Some change to the code base. So if I close that out and I run git status, it's going to show something different now. Two different references here. So you have the snapshot a while ago when you first added it to the staging area. And in that case, the snapshot just says hello world, right? But we haven't committed things yet, and you've changed the contents of the file. Now it says hello world 2, but you haven't taken a snapshot of that just yet and set it on the trunk. And that's what it's telling you right here.

and set it on the truck. And that's what it's telling you right here. There are changes of this file that you have not taken a snapshot of and replaced on the truck. So if I were to say git diff, this is a new command. Show me the difference or the changes made to index.txt when compared to what we currently have. If I run it, notice minus means what you had, and plus, in green, in this case, means what you have now. So the difference is we added a 2 here. Now let's imagine that we say git commit with a message of 'first commit' like we did before. All right, we run git log.

Now let's imagine that we say git commit with a message of "first commit" like we did before. All right, we run git log. Everything looks great. But now we run git status, and yeah, we still have changes here. I hope that makes sense. Every time you run git add, you're taking a snapshot. So if you take the snapshot and then you change things, well, obviously those changes aren't represented in that snapshot. So when you finally do run git commit to send it off to the warehouse, it's going to have the old snapshot, and it won't be reflective of the most recent changes.

So when you finally do run git commit to send it off to the warehouse, it's going to have the old snapshot, and it won't be reflective of the most recent changes. And many times, that's exactly what you want. But otherwise, if you run git add to add a file to the staging area, and if you change that file, you will want to run git add again to make sure you have a snapshot of the most recent changes. Now generally, you don't have to worry about this too much. The typical process is you work on your code base, you make some kind of change that you can describe. Then when it's all done and ready to go,

you make some kind of change that you can describe. Then when it's all done and ready to go, you switch to the command line and you say git add . In this case, . would be all the files that I've changed. Add them to the staging area and git commit with a description of what you did. Fixed a bug related to whatever. And you're done. You have a commit that represents all of the changes that you've made. Now eventually, I'll show you how to use a service like GitHub to push up your changes so that they can be reviewed by others.

Now eventually, I'll show you how to use a service like GitHub to push up your changes so that they can be reviewed by others. But otherwise, if you're still working locally, this is still useful to you. Now no matter what, if you ever need to reset or revert your code base to how it appeared, if I run git log, at this point in its lifecycle, you now have a way to do that.