FREELessons: 24Length: 3.1 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

2.2 Staging and Statuses

After making some changes to our project, we’ll want to stage those changes for committing, so we’ll learn about the `git add` command. Of course, you’re often going to want to check the state of your repo, to `git status` is a good thing to learn early as well.

2.2 Staging and Statuses

So far, we've created a project and initialized that project as a Git Repository. We also created some content in the form of a README file and now we're ready to actually start tracking that content with Git. So I've mentioned creating commits a couple of times already, but there's actually an intermediate step and that is staging the file. So we're gonna talk about what that is and how to do it in this screencast. So I've opened a Terminal here and we'll just cd into our project directory. Now if we list the files here, you can see that we have a README file. Now we know that we have not yet told Git to track this file. But if we had a lot files in our project and over time we were adding files, etc. It would get confusing and we might not remember which files have we told Git to track. And which files have we not yet told Git to track? Well, Git can keep track of what files it is tracking and which files it is not tracking. And we can find that out by looking at the git status command. This is the status of a repository. So let's look at this output here. We start with a couple of lines. Don't worry about those right now. Those will make more sense as we go on in this course. Then we have a list of untracked files. And you can see currently, that's only the README. Now there's an important differentiation to make here. Git can track files. As you can see, we have an untracked file, which implies that we can track files as well. But git doesn't record files, it records the changes to those files. It actually records changes in content, not specifically the changes in files. Now you might think this differentiation doesn't really make sense. But hopefully, as we move on a little bit, you'll understand how this works. As you'll notice, we actually have a couple of prompts here which suggests what our next step should be. We have this message nothing added to commit but untracked files are present use git add to track. So let's do that. So let's do git add and this is where you give it the file or files that you want to track. And we're just gonna say README in this case. Now I just said the files that you want to track, but this isn't specifically the files you want to track. We'll talk about that in a second here. So I've just added it, we don't get any output. Let me clear the screen and run git status again. Now we have a bit of a different set of output lines. And this is changes to be committed. New file, README. So remember Git tracks, content not files. What we've just done when we said git add README, is we have added the README file to the staging area. Now, let me talk about the difference between the staging area and our actually committed stuff in the repository. A good analogy that I like to use when talking about this, is that a factory that ships products. When we're working on a file, that's as if the file is in the factory. We're working on it. Our end goal is to actually ship that product, right? Or commit the file. When we make a commit, as you recall from our introduction. We said, that's like taking a snapshot of our project at a current position. So that is like putting a package on a truck and shipping it out from our factory. However, there's an in between step that's very important. And that is packaging the product and putting it on the loading dock to be put into the shipping truck. That's what the staging area is and that's where we we've just moved this README file. We've said, we've created this README file. We want to ship it in our next truck. So put it on the loading dock. That's what the staging area is. We've said, we've made some changes to this README file. We want to put it in our next commit. So put it in the staging area, or stage the file. Now since we actually have not tracked this file before, Git has done two things. It's added the README to the list of files it tracks. You can see this by the fact that git is saying that we now have a new file. The file wasn't just created. However, it was just added to git's list of files that it's gonna track. The second thing we've done here is say, we want to commit the current changes or the current content of the README file. So the README file in its current state, is what is going to be committed in our next commit. It's not exactly committing the README file, it's committing the changes in the README file. And we can actually see this at work if we go in and change the README file right now. So if I come here to the bottom of this README file. Let me just add another line and I'll save and close that. If I clear my Terminal again and run git status, you can see our output is again different. We have changes to be committed just like we did before and we have our new file, README. But then down here we have a section entitled Changes not staged for commit. In our analogy, this would be saying changes not packaged for shipping. Changes not on the loading dock for shipping. And what we have here is a modified file. The same README file. So we've just made changes to the README file. And this is where the product shipping analogy kind of breaks down, cuz you can't have a project in two places at once. However, what we've basically done is said, in our README file there is content. We had a bunch of lines of text in our file. And when we told git to add the file, that's adding it to the staging area. We said track this file and add those current changes to the staging area. Then we went made more changes to the file. And those changes have not yet been added to the staging area. If were to make a commit right now or if we were to load and send out our shipping truck. The changes that we just made, that line we added that said add another line, that would not be shipped. That would not be committed, because we have not yet told Git to stage that content. Now let's do this. Let's create another file called TODO and I'll just add one to do item here saying learn to make commits. And if I save and close that, again I'll clear my screen. And again, we're gonna run git status. Now notice we have a third section here, which is the section we actually started with, untracked files. A lot of times, this is what you might see if you are partway through some work in a project. You'll see changes that you have staged that should be committed. These are things that we know that we want to put in our next commit. Then there's gonna be content that is not staged for commit. This is something that has changed since our last commit, since our last snapshot. This is something that's been produced since our last truck was shipped. But we have not said we want to put on the next truck. And then finally, there's untracked files. And this is a file as you know, that we have created and git is not tracking yet. And if I go make a change to this file, I can change it as much as I want. And what we see in the git status output will never change for that file. It'll just continually say, it's an untracked file until we tell git it to track it and then it will respond to changes in that file. Until then, it's just an untracked file. So, let's say that we want to add those changes that we made to the README file to the staging area before we actually make our commit. How would we do that? Well, it's the very same command. Git add README. If I run that and now run git status again, you can see down here that we have changes to be committed. Are just this README file and then untracked files is TODO. So since we added those changes to the staged area, git now sees that file as a single thing. So the git add command is not exactly telling Git to add this file to its list of tracked files. It's telling Git to add the changes that have been made to this file to the staging area. If the file has not been tracked before, then Git will begin tracking that file as well. And that's just kind of a nice side benefit of the fact that we're telling it to stage the changes that have been made to that file. Now up until now, you've just seen me use the git add command by passing it a single file name. However, this is just like any other command-line utility. And you could say, for example, commit all the js files in the source folder or just commit the whole source folder just like that. Or you could say, git add any file that begins with the word password. So just about any kind of way you can refer to files at a normal Unix command, you can tell git to add the files. Often, what will be done when you initially create a project, is you'll initialize the repository. You'll make some setup and then you will do git add and you'll just use dot. And the dot just stands for the current folder, right? And it just adds everything within the current folder to the staging area. So now if I do git status, you'll see that we actually have two files now. The TODO file has been added to the staging area with our last git add dot command. So that is the git add command and the git status command. Now that we've added these files to the staging area, we're ready to actually commit them. So let's do that in the next screencast.g

Back to the top