Introduction to Git Recap | Learn with Dr G

>> Hi everyone and welcome back to another episode of Learn with Dr G, that's me. Today we're going to be doing a quick recap on the intro to Git live stream that we did previously. So stick around.

[MUSIC] We did a live stream where we introduced Git following along on this Git module at aka. ms/LearnWithDr/IntroToGit. There were a couple of questions and I also just wanted to do a quick short recap of what we learned.

I've created a short PowerPoint deck to visualize what we're going to be doing in the terminal. Now, if you followed along on the Learn module, you know you get to actually use a terminal that's in the sandbox inside of Learn in the browser. In this case, I'm going to be using Windows Subsystem for Linux and Ubuntu terminal right here on my machine.

Same thing though. The first thing that we need to do is some setup. We're going to start by configuring our username and e-mail, this will help Git know who is making what commits, or saves of the file.

You can see an explanation here. It looks like we set our username and our e-mail. Next, we're going to create a new folder called cats and initialize it as a Git repository.

We do this with the git init function and this basically just let's Git know that this is a folder, aka repository. Now, we have created a new folder called cats, we have changed directories, aka gone into that folder, and we have done a git init command to initialize this as a new Git repository. Next, we're going to create a new empty file called index.

html and then we're going to check the status to see what Git knows about our current file or repository. What we can see here is that we've created a new file called index. html and we can see it in our folder by typing ls or list and when we did a Git status, we can see that Git knows about this file called index.

html. But it is an untracked file, meaning it's not going to be tracking whether or not you make changes to it. To make sure that Git is tracking those changes, we're going to do git add.

. This says add everything that's currently in this repository to your list of files that you're tracking. When we do this we can see that the Git status changes to show that there is a new file being tracked and that those changes, aka the new file, are ready to be committed.

We can go ahead and commit those files using a git command. Let's check out how this worked. Basically, we say git commit as the command, we specify a file, in this case index.

html, and then we also specify a message. This commit message create an MD index. html file will help us know what version of our repository that commit is representing.

Good commit messages are crucial to not only collaboration but also remembering what steps you have taken to build your own coding project. After this command is finished, we now see that Git knows not only about this folder called cats but also about this empty file called index. html and it's assigned this hash to that version of that entire repository which contains that folder and empty file.

Now, we can add some actual code to our file. Let's go ahead and do that. When we run code, index.

html, Visual Studio Code opens up and we can type in some code, in this case a header. We save that file and then we can check to see what Git knows about it. You can see that Git now knows that the file has been modified but since we have not committed yet, Git still does not have that modified file saved as a new version of the repository.

To do that, we need to do another commit message. In this case, we did git commit and then we did -a instead of specifying index. html.

-a lets Git know that we want all of the files that have been changed or deleted or added to be saved in the new version of that repository. We're still going to add a message, in this case, add a heading to index. html.

Now, Git does know about the two different versions that we have committed or saved so far. One of them had a folder called cats with an empty file index. html, and the other had a folder called cats with a file index.

html with some code in it. We can run the Git log command to see these two different versions or two different commits of our repository. You might notice that the hash values that I have over here in my terminal are different than the hash values that I have over here in my PowerPoint.

That's just because I made the PowerPoint ahead of time, they're just different numbers. Those were some of the initial set of commands. Doing the git config commands to set your name and e-mail, doing a git init to initialize your repository, and then doing some basic add and commit commands to start tracking and saving versions of your files or your repository.

Let's do a couple more of those basic commands just to make sure we have an understanding. First, let's go ahead and make some more changes to our index. html file.

You can see that we've added a lot more html code to our index. html file. If we were to do a git status at this point, you can see that Git knows that that file has been modified but since we haven't done a commit yet, it has not saved a new version.

We can even see what the difference is between the file that's in our working directory and the most recently saved version that Git knows about. Running git diff will show us that one line from that file has been deleted, this original header, and that 12 lines have been added, this entire block of HTML code. Let's go ahead and make that commit.

After making that commit, we can see that our working directory and our most recent version of our repository saved by Git look identical. Let's go ahead and add a new file. In this case, we're going to add a.

gitignore file, which is a file that contains all of the files or file types that we want Git to not track. In this case, we do not want to track backup files or temporary files. We can save that gitignore file and let's go ahead and make another change to our index.

html file. I don't really like the word feline, I'm going to change that to furry. Great.

Now, we've made two different changes. We've created a new file and we've modified an existing file. If we did git status, you can see those two different changes and if we run git add and then dash capital A, what we're going to do is we're going to add any file that is not currently tracked by Git to the list of files that Git wants to track.

In this case, the only file is the . gitignore file but if we had a bunch of other ones, it would include those too. At this point, our working directory looks a little something like this where we've made some changes to index.

html and created the . gitignore file. But we still don't have a new version of the Git repository that has been saved because we haven't done a commit yet.

Let's go ahead and do that now. For this commit message, we did another slightly different thing. We did -am instead of -a-m, or including different file names.

This is just a shortcut way of making sure that we're including all of the changes in this commit and we're including a specific message, making small wording changes and ignoring the editor backup files. Now, we can see that our working directory is identical to our most recent version of our repository that Git knows about. Let's go ahead and make our CSS directory and our site.

css file. With these three commands, we've created a new directory called CSS. We've created a new file called .

git-keep that's inside of that CSS directory. This is basically just an empty file that Git doesn't really care about but that let's Git know that it does want to be tracking this file structure. Otherwise, Git does not track empty folders.

Then we added the entire folder, any of the files that were within that folder, for Git to track. Again, if CSS folder did not have any files in it, it would not track it. At this point, our working directory does have the CSS folder, but again, we don't have a new version saved yet because we haven't done a commit.

Before we commit, let's go ahead and get rid of that git-keep file, and actually add in our site. css file with some CSS in it, and then modify our index. html to use that CSS.

You can see that we did add this link to the style sheet in our index. html file, and we've created this CSS file over here in the CSS folder. We can actually see that by going into the CSS folder and doing an LS.

We can see that now we only have that site. css file. Remember, Git is not currently tracking site.

css. Because even though we said git add. the entire CSS folder, site.

css did not exist when we did that. So it's currently an untracked file. Let's go ahead and fix that with a git add.

again. This will add all of the untracked files that are in our current repository to Git's list of files that it wants to track and we can finally do the commit. Then that way, our working directory with that new CSS file inside of the CSS folder, matches our most recent version that Git knows about our repository.

We can do a quick git log --oneline, just to make sure that we do have five different versions of our repository saved, just like in our visual over here on the right. That wasn't so bad. But I don't know if you caught it.

There was actually a typo in that site. css file. Now, it was a quick typo that I just discovered right now.

I don't really want to create another commit. Typically, we like to reserve commits for when we make a change that we might want to come back to. It's a point in time where we feel comfortable with the code.

While I do encourage committing often because you want to make sure that you make those saves. You don't necessarily want to commit on every single tiny little addition or subtraction to your code. In this case, there's just a really quick typo that I want to fix and I don't want to have a whole commit just for that.

It might get confusing if I need to roll back, which we'll talk about later. Let's go ahead and make that change really quick. The issue was I forgot my curly brace on the end of the first line.

I'm going to save my file. Then what I'm going to do is called a git commit --amend --no edit. Basically, all I'm saying is that that last commit that we just did, I want to make an amendment and I don't even want to change the commit message because the commit message is exactly the same.

Nothing has changed with my code, it was just a typo that I fixed. After we run this, Git will still know exactly the same information, but that typo will be fixed. We can verify this using the git log command.

You can see here that we still have the same five commit messages or versions saved, and at that last commit message, making a simple stylesheet hasn't changed, and it's just the same thing. But then there's the dreaded, Oh, my gosh, I deleted a file. Let's see two different ways that you can recover from deleting files.

The first way is when you do a simple rm of a file. Rm or remove when we have it exactly like this, is basically just removing the file from our working directory. Let's confirm first by doing an ls to list all of the files in our directory.

We can see that index. html is in fact there. Now let's do rm, index.

html and another ls. We can see that index. html no longer exists in our working directory.

When we do this, our working directory doesn't have index. html, but git in its most recent version, still does. This is great news, because it means all we have to do is ask Git to check that file back out so we can have that copy back on our working directory.

We do this with git checkout -- and then the filename. Doing another ls, we see that index. html is back and it looks like we're good.

Our working directory now matches what Git knows, its most recent version that is saved. But what happens if you do a git remove? Git is now going to think that you no longer want to track that file.

If you were to ask git to just check that back out, it's going to say, "I don't know what you're talking about. " Doing this, we can verify that index. html is no longer there.

If we were to try that checkout trick, it doesn't work. But what we need to do, is a git reset HEAD index. html.

Basically that is telling Git to reset the tracking of the index. html file to the most recent commit or HEAD. When we do that, we are actually able to recheck out that file.

Though not here in our working directory, but we can check it out and it's back. Now our working directory and our most recent saved version of our repository are the same again. But what if you make changes to a file and you commit those changes, and then you realize you've made a big mistake?

Don't worry we got you covered. First, let's get us into the problem. We're going to open up our site.

css file. We're going to delete everything from inside of it and we're going to actually commit that. What's going to happen, is our CSS file over on our working directory is going to be empty.

The most recent saved version that Git knows about is also going to be empty. We've erased all of the contents and let's commit. It's been committed.

We can verify this with the log. It's all been deleted. This is currently what our most recently saved version of our repository looks like, an empty CSS file.

Don't worry though, we can use that same reset trick. This time we're going to ask it to reset, for sure by telling you, I want you to with that hard option to the version right before HEAD. Then we're going to check out that file again.

First we're going to just make sure that Git is now pointing to the right version of our repository that we want it to. Then we're going to go ahead and check out just that file once again. Well, after doing a reset, we can see that HEAD is now at 87105bo, which is not the most recent version, but the one right before it where we did actually add that stylesheet.

Then we can go ahead and check that back out, and never fear everything is fine again. The last thing that I want to recap in this video was a question that we got on the stream, regarding how we can revert back to a commit that wasn't just the most recent one, but well before that. First what we're going to do, is we're going to add dogs to our html file.

Now this is supposed to be an app about cats, but we're going to sneak dogs into there. Let's go ahead and make those changes. Now we have a new version that has been saved with those new changes to index.

html. If you wanted to just undo those changes, you can do a git revert -- no-edit to the HEAD, which basically creates a new commit that undoes everything that you just did. Let's check out what that looks like.

If we look at the logs again, we can see that we made a commit where we included dogs. When we did the git revert, basically we just wanted to revert that commit exactly the same commit. Exactly those changes, we just wanted to undo those changes, but it does get saved as a new commit.

If we were to open index. html again, you can see those dogs are gone. We figured out how to go back and forth between making changes, removing files, all of that.

But let's go back a couple of commits instead of just the most recent one. First, I'm going to add birds, and I'm going to go ahead and commit that. Then I'm going to go ahead and add some fish and also commit that.

Let's check out our log. We can see that after the revert, we have this commit here where we added the birds, and we have this commit here where we added the fish. I want to get back to the point where we only had cats in our app.

What we're going to do is a git checkout and specifically use the hash for the one that we want to get back to. Then we're going to have dot at the end to say this repository, all of it. I want you to just bring me all of it, please.

Let's grab the right hash that we want. In this case, it's this one. After that's done, we can see nothing has changed in our log yet, but our index.

html file has cats all by themselves as they should be. The last thing that we want to do to make sure that we solidify that change is to make sure that we commit because our log file hasn't changed. We just checked that code back out, replace it in our working directory.

Now we want to make sure that Git also has the correct version that no longer has those pesky dogs, birds, or fish, and only has cats. Perfect. I think our code is all set.

Now, there were a couple of other questions around squashing commits and things like that. But we are going to get to those in future live streams and recap videos just like this. If you'd like, you can follow me on Twitter @drguthals or #LearnWithDr, where we'll announce future live streams and pre-recorded videos that go live.

You can also check out this learn module at aka. ms/LearnWithDr/IntroToGit. If you want to see the entire playlist from this, what you didn't learn in school mini-series of the Learn with Dr G show, you can head over to aka.

ms/LearnWithDr/WYDLIS_Videos, where I've compiled an entire playlist of just these videos. Last but not least, I've also compiled a list of all of the Learn modules that we will be going through in this entire mini series, which you can find at aka. ms/LearnWithDr/WYDLIS.

Thanks so much for joining and I can't wait to see you on my next stream. Bye everyone.