>> 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/LearnWithDrG/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 #LearnWithDrG,
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/LearnWithDrG/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/LearnWithDrG/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/LearnWithDrG/WYDLIS.
Thanks so much for joining and I can't wait to see
you on my next stream. Bye everyone.
[MUSIC]