FREELessons: 24Length: 3.1 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

6.1 Adding Interactively

We're getting closer the the end of this series on Git and to be honest, you're already familiar with all the basics of Git. However, I wanna take it one step further and show you some of the really cool and slightly more advanced Git features that you'll find useful in your daily Git usage. So in this screencast we're gonna be talking about interactive adding. You learned a long time ago how to add a file to the staging area. git add filename, right? However, sometimes when you've made a lot of changes since the last commit, you want to be more specific in what you commit. Maybe you only want to commit certain changed files. Or maybe you only wanna commit certain parts of changed files. Well, Git's interactive add feature makes this really easy. Of course, we're going to have to make some changes first. And as you can see, our working directory is clean. So let's see, what files do we have to work with here? I'm gonna open up fix.txt. Let's add a line above it. We'll just add a markdown header calling this FIX.TXT. Let's open up our TODO file here and mark orphan branches as done. We'll add another to do item here that says learn about showing Git info in your command prompt. And then at the top here we're gonna add a markdown header saying this is the TODO file. And finally, let's open up the README file and remove this part here at the beginning of the header. And then maybe I'll just put my name down here in the footer. All right, so we've made a bunch of changes, and if we run git status, you can see that, whoa, three files have been modified. Okay, we don't just wanna add them all. We wanna maybe do things in chunks. So what we're gonna do here is run git add -i. -i stands for interactive add and as you'll see here, it opens up almost like a sub-prompt. Down here you can see we have the What now, and this is actually a prompt. We're in a specific prompt for Git interactive add. So let's check out what output this gave us first. As you can see up here, we have three files that have been changed. Over here, we have a list of what has been staged, and over here, we have a list of what has not been staged, and then we have the path for the file. Now that might throw you for a loop thinking why would you have both a staged and unstaged column? After all, a file can be either staged or could not be staged, right? Well actually, it's not that simple. What we're gonna see with interactive add is that we can actually add part of a file to the staging area and leave part of the file in the working directory. And that's when it'll be useful to see when stuff is unstaged and other stuff is staged. Now if you look at this specific content of the unstaged column, you might recognize that these are exactly the numbers of the lines we've changed in those specific files. For example, in the fix.txt file, we added a single line, in the README, we subtracted two lines and added two lines. And of course remember, whenever we make a change to a line, the line is like the basic unit of changes in GitHub, so when we make a change in a line, it says that we removed one line and added another line. So in README, we actually just changed two lines, but Git shows it as removing and adding two lines. And then in TODO we added three lines, removed one line. All right, so down underneath that, we have the commands, down here. As you can see, we have eight commands. First one is status, update, revert, add untracked, patch, diff, quit and help. All right, so the way this works is in our command prompt down here, right where I'm typing there, we can either type a number or a letter to indicate which command we want to use. I hope you can see that the first letter of each of the commands is highlighted in blue and this would indicate what letter you would type if you wanted to use that command. Otherwise, you can just use the numbers. So, let's start with number 1, status. We'll type a 1, and hit Enter. And you can see that that just outputs the status of our working directory. It's the same information that we had above. Okay, that's pretty basic. What about update? Well, update is just what you would consider to be your normal Git add. It just adds all the changes from a given file to the staging area. Let's hit 2, and I'll hit Enter. And so now you can see we are almost in a sub-sub-prompt. Notice that our prompt changed from What now, to Update. So now, we're within the Update prompt. So now we have to choose which files we want to update or which ones we want to add to the staging area. Let's say we wanna add fix.txt to the staging area. We can reference that file either by typing 3 or as you may notice, the f here in fix is blue, so I could type f instead. I'm gonna go with f so you can see how that works. Now, notice what happened it didn't stage it right away. It still says that the file is still unstaged. However notice this new little asterisk over here by the 3. This means that when you are finished with the Update prompt we're gonna stage the fix.txt file. All right, I'm gonna go ahead and stage file 2 as well. And now you can see that both 2 and 3 have the asterisk. Now let's say I change my mind about file 3. I actually don't want to stage fix.txt. Well it's very easy, I just do a -3 instead. And as you can see the asterisk beside 3 there is gone. And now it is not going to be staged when we finish with the Update prompt. I actually changed my mind again, I'm gonna wanna stage 3 so we're gonna have 2 and 3. You can see they both they have the asterisk selected. So now to say okay we're done with the Update prompt, all we have to do is hit Enter again and not give Update any command. Now you can see we got the output updated 2 paths, and then we have our commands shown down here. So we're back to our initial interactive add prompt. But let's check out the status. Those two files now have nothing unstaged and all those changes that they had are now in the staged column. Excellent, so those files have been staged. Let's move on to command 3, which is revert. As you might guess, revert is the opposite of update. We use update to add them to the staging area, you saw how we could use the minus sign and then the number of the file to remove it from the staging area. Well, you can do the same thing with revert, so here we are on the Revert prompt. As you can see, right now file 3 is indeed staged. I'm gonna type 3 and now file 3 has been marked for unstaging. If I type -3, you can see that the asterisk beside file 3 is no longer there. Therefore it still is gonna be in the staging area. I'm going to now do 2, and I'll hit revert again so now you can see that we have reverted one path. If I again run command 1, you can see that the reversion of file 2 occurred. Now file 2, the TODO file, has been unstaged, so only file 3 has been staged. At this point I'm gonna use command 7 to quit the interactive add prompt. So I'll press q, hit enter, as you can see, we have the message Bye. And now we're back to our normal prompt. If i were in git status, you can see that the changes we've made in interactive add have come through here. When we left interactive add, the only thing that was staged was the fix.txt file. Now down here in the output from git status you can see that's exactly the case. So we're gonna commit that. I'm gonna say git commit -m tweaked fix.txt and now if we run git status, you can see that we only have two files left to commit. Well, I'm gonna clear the screen and get back into the git interactive add console so we can look at a few other things. Command 4 is add untracked and this is not gonna be of much use to us as you can see, since we have no untracked files, this is kind of useless to us. But this is for files that have never been committed before. And you can take my word for it that this would act in the same way the update or revert commands did in that you could either use the number or the highlighted letter from the path name to add the file to the staging area. Of course using the negative number to undo that if you wanted to before you actually did the tracking. So I'm gonna hit Enter to quit the add untracked prompt, and now we come to what might be my favorite one. This is the patch prompt. What this allows us to do is stage part of a file. So we're gonna choose to stage part of the README file, so I'll hit 1. As you can see that's been marked at be partially staged. We're just gonna leave that as the single choice now. And when I hit Enter to say I'm finished choosing files for the patch update, now the magic actually happens. Notice what we have here. So first of all, we have a diff that's shown. This is a diff of the README file, before and after the changes that we've made in the working directory. As you can see, we subtracted this first line and added the shorter first line, and we changed the footer line as well to include my name. Down at the bottom we have our prompt, Stage this hunk. And we have a bunch of options, y, n, q, a, d, /, s, e, ?. Well, it seems like the most appropriate one here would be question mark, so we can actually find out what all this stuff means. And once we run that, you can see all of this printed out here. So we can say y means stage the hunk, yes. n means do not stage the hunk, no. q means quit, don't stage this hunk or any remaining ones. a means stage this hunk and all later hunks, and you can go all through this. But, the one I'm most interested in today is s, split the current hunk into two smaller hunks. This gives you the ability to really customize exactly what lines get added to what command. So down here you can see that we have a change at the top of the file, a change at the bottom of the file. And it's saying do you want to commit those both at the same time? I'm gonna press s, and hit Enter. And what it's gonna do is look at the content of that diff and say, okay, where might he want me to split it? It's gonna split it somewhere, probably near the middle, and now you can see it's saying, okay, we've split it into two hunks. Do you want to stage the top change? In this case, that's just the change of the header. So I'm gonna say yes. I do wanna stage that. All right now we have, do you wanna stage this hunk? And I'm gonna say no, I don't wanna stage that. Well we're back to the commands, which means that every hunk has been spoken for. So now, I'm gonna run command 1, and now this is where it gets interesting. Notice that for file one here, we've staged the changing of one line, and we've unstaged, or we've left unstaged, the changing of another single line. So now our README.markdown file is both staged and unstaged. We'll see how this works in a second, but right now let's look at our last command here, command 6, which is diff. And diff just simply allows us to run the diff on a file. As you can see, there's only one file showing up here, and that's our README.markdown file. So that should give you the intuition that this diff is actually giving us a diff between our staging area and the repository. All right, so let's review the diff for that file. And as you can see, what changes have been staged? We've staged the changing of that header line. All right, so there's nothing more to see there. And as you can see we've been taken immediately back to our initial sub-prompt. So now, I'm gonna hit q. Let me clear this page. And now I'm going to run, git status. And now notice something pretty interesting. Changes to be committed, the modified README file. Changes not changed to be committed, the modified rREADME file. That README file is both staged and unstaged. We've used the patch command to change part of that file, and not the other part of that file. So now I am gonna run git commit -m, I can say updated header on readme I'll commit that. Clear the screen and now when I run git status you can see that there's still README.markdown and TODO to stage. Well that is the git interactive add tool. If you're thinking about git the same way I do, you might think that's great. And the most useful part of that is gonna be the patch command because pretty much all the rest of that you can do just as easily with the normal git tools from your normal command line. And that's why there's the git add -p, which is just almost like a shortcut to patch. I can git add -p and you can see right here immediately it starts going hunk by hunk through the file. We're asking, what do you want to do with the last hunk of the markdown file? I'm gonna say no, I don't want that. Here you can see that we have the changes to the TODO file. I'm gonna say s to split that. It's gonna say do you want to stage the header? No, I don't wanna stage the header. Do you want to stage the last two lines there? I'm gonna see can I split it again? It looks like I can't split it again. That's the finest grain its gonna do. All right then, I'll say yes, I'm gonna stage that. Now you can see we're taken right back to our main prompt. If I do a git status, you can see that the TODO file is in both places. If I run a git diff on the TODO file it will show us the difference between the staging area and the repository. As you can see we're about to add a single line there. Then I can go ahead and git commit that and say added header to todo. So there you go. Those are some more fine grained ways to add your files to your Git staging area.

Back to the top