Instructor: Let's now quickly go over the basics of Git.
And this video is by no means
gonna be a complete overview of Git.
All I want to do here is to get you started
as quick as possible with Git,
so that we can then push our project to GitHub.
All right, now before we can do anything else with git,
in each repository,
we should have a git ignore file like this.
So if VS code didn't create it automatically for you,
as it did for me in the last lecture,
then please go ahead and create this file right now.
So it starts with a dot,
and then Git ignore.
And inside of this file,
we can put all the folders and also files,
which we want Git to ignore,
or in other words, folders and files
that we do not want to get into our repository.
And node modules is a perfect example of that.
Because, well, we can always get
this code back from NPM, right?
It is not part of our original source code.
And so therefore, we don't need it in our Git repository.
And actually, the same is true for our dist folder.
Right, so the dist folder,
essentially only contains code
that was built from our source code.
And so again, this is actually code
that we do not need in our Git repository.
So usually, in the repository,
we only want like the original source code,
and everything that is necessary
in order to basically compile our final project later.
So let's actually also exclude the dist folder here.
Now, this is not mandatory,
and some people want also to keep their dist folder
in the Git repository.
But personally, I think it's a good idea not to include it.
And so you see that now, it got grayed out here as well.
And the same for the parcel cache folder.
So that we also don't want.
So .parcel-cache.
So that's gone now.
And now here, VS code shows us
that there are basically 28 files
in our repository that are pending changes.
So this here is enough for our Git ignore.
Now only if you're using the Mac,
you can add one type of file here, which is the .Ds_Store,
which is some kind of weird file
that Mac OS sometimes adds to our directories.
But with this here,
I think we're already at a good starting point, okay?
So let's now run a Git command called git status.
And so this shows us here,
that all of these files are untracked files.
And we can also see that we are on branch Master,
and that there are no commits yet.
So all of these files here are untracked.
And so now we need to track them,
which in terms of git means to add them
to the so called Staging area.
So you can also see here in VS code,
that these files are now untracked.
So that's what this U stands for.
Okay, but now, let's add all these files
to the staging area by saying git add,
and then dash A, which stands for all the files.
Now, we could also add files manually.
So one by one, but usually that's never necessary.
So I will simply add all of my files now.
And so these files are now basically part of the repository.
Okay, and so now here it says, edit.
And so these files are now basically tracked,
they are active.
Okay, then let's say we do some change in one of them,
let's say in the controller,
let's just log something to the console
in the init function, let's say welcome.
And so now you see that this file was modified, right?
And also immediately here on the sidebar,
VS code tells us that something has changed.
And so green here means that something was added.
And when we click that, we can actually see the change.
So the plus here means that something was added.
And if we see git status now again,
you will see that all of these files here,
are ready to be committed.
So they are being tracked,
and then there's this modified file.
And so in order to now commit all these files
to our Git repository, I need to run git add all again.
So now you see that it is back to just being added.
And also this green bar here is gone.
All right, and so now we're ready
to finally commit these files.
And committing the files basically means
that we really save the modifications
of all the files to the repository.
So adding the files, like this here,
is basically just a pre step before the commit.
So a commit is gonna be like a snapshot
of your code at a certain point in time.
So each time before you make some
significant changes to your codebase,
you should always commit.
And so then, if necessary,
you can go back to past commits,
and delete any modifications that you did
that were maybe wrong.
And we will see how to do that actually later
in this lecture.
But for now, let's commit what we already have here.
So git commit, then dash M, which stands for message.
And then here, we need to specify a string,
which is the commit message.
And so usually, the first commit is always
gonna be called initial commit, like this.
Now, okay, and that's it.
Now, they're all committed.
And you see that all the files,
now look normal here again.
All right, and if we now take a look again, at git status,
then you will see that there is nothing to commit,
and the working tree is clean.
Alright, so in summary,
whenever we initialize a new Git repository,
usually I immediately add all the files,
so I do git in it, then after that,
immediately I run this command.
So Git at all the files.
And then immediately after that,
I commit everything as the initial commit, all right?
Now, let's say that we do some modifications here,
in multiple files.
But we actually introduce some kind of a bug,
not writing any real code,
I will just put a bug here now.
And it turns red, because I have
a special VS code extension for that.
And let's say I also have now some error
here in the model.
Okay, and so this is just to simulate
that we introduced some real bucks.
So if you wanted to go back on all of these files
to the previous commit,
then you could simply write git reset,
then dash dash, hard, and then HEAD,
all in uppercase like this.
And now watch what happens to this file
as this command is executed.
So, you see that it's gone.
And to two files here that previously had the M,
for modified, are also now back to normal.
And debug that we introduced here, is also gone.
All right, and so this is the easiest way
to going back in time, basically, to the previous commit.
But now, let's say that you actually had already committed.
So let's say that here, you now had an alert,
which says, hacked.
And it doesn't really matter what code it is.
But let's say this is another bug
that you introduced for some reason.
But you didn't really notice that it was happening.
So let's say here as well.
All right, so you see now
these two files are modified.
And now you want to commit these changes.
So you think you added a great new feature.
But actually, you just introduced a bug,
which allows users to get hacked.
But anyway, you don't know that yet, let's say.
And so you add all the files to the staging area,
and then you do git commit
with the message of new feature.
Okay, and so now these modified here are gone.
And our code is now committed.
Now, let's say you keep working on the code.
But eventually you notice that you have these bugs here,
which allow users to get hacked.
And so you want to basically now delete
the last commit that you did, right?
So you want to go back to the previous commit.
So to do that,
you need to take a look at that previous commit
and you can do git log for that.
So here you have basically a log
of all the commits that you did.
So this one is the last one.
So the new feature.
And it has basically this ID here.
And so this has currently the head.
And so that's why previously
we could reset using this head keyword.
But now you want to go back to this commit,
so to the initial commit, right?
And so let's copy this ID here, basically.
And it would be enough to take the last seven here,
but I like to simply copy everything.
So select and copy.
And now to get out of this log here,
you need to type a Q, so Q for quit.
Okay, so Ctrl C will not work there,
you have to use key like this.
And sometimes you even need like, colon and Q.
But anyway, let's now do again, git reset,
hard, and then the ID of that commit.
So let's see.
And now that hacked log is gone from here,
and from here as well.
And so we are now back in that initial commit.
And indeed, that's what is set right here.
So the head is now at the initial commit.
However, moving between commits like this
is a little bit dangerous.
And so instead, when we plan on doing a lot of changes,
usually, we simply create a new branch.
So let's write git branch.
And this will simply list
all the branches that we currently have.
And so right now, we only have the master branch.
And the star here means that that's the branch
that we are currently in.
And now again, to close this, you need to write a Q.
Okay, but now let's create a new branch.
And so that new branch is then basically
going to be a copy of the current master branch,
in which we can develop new codes and adding new features,
but without affecting the codes
that is in the master branch.
So it's basically a parallel track
in which we can develop new code,
but without affecting the original code that we had before,
and which we knew was already working.
And so this is a great way of preventing bugs
in our main code base.
So we create a new branch,
by writing again, git branch, but then here,
we can also specify now the name of the branch.
So let's call this one new-feature.
Okay, so we created a new branch,
but we didn't switch to that new branch yet.
So to switch to that branch,
we write git checkout, and then the name of the branch.
And so it says switched to branch new feature.
So let's quickly add some modifications here,
let's add a new function.
Newfeature is simply a function
which logs to the console
Welcome to the application.
Okay, and we also delete this code from here.
And then we want to call that function down here.
So, nothing significant.
This is again, just to simulate.
So this one turned now a green
because we changed something from the original code.
And here it is orange, because we changed something.
And if we were to delete something, for example,
then it should turn red, which right now is not happening.
But anyway, if we click here,
we can see exactly what the code looked like before.
So these two lines of code are gone
and this one is new.
And so this in itself, can be very handy
and a great use case of Git.
But anyway, let's put this very important line here back.
Okay, and so let's now add this change to the staging area.
So Git add all.
So we always have to do this before committing,
and then git commit message,
then edit new welcome feature.
All right, and that's it.
So we just created a new feature,
but this new feature is now in this new feature brand.
So let's check that out again.
So git branch,
and so now we have these two branches.
So master and new feature, and this one is the current one.
Then again, Q to Exodus.
And now once we are done with this new imaginary feature,
let's switch back to the master branch,
so that we can then integrate these changes
into our main code base.
So which again, is in the master branch.
So that is git checkout, and master.
And so now, as I execute this,
you will see this code here going away,
because that is the way the code looked like
in the master branch.
Okay, and so this proves
that there are now really like two different tracks
with different versions of the code.
So in the master branch, we have this code.
And in the other branch, we have that code that we just saw,
and that just disappeared.
But now we can then merge these changes together.
So when we are in the branch
into which we want to add the new code,
we can use Git merge, and then the name of the branch,
which contains the new code
that we want to merge with the current branch.
And so that is the new feature branch.
And so now watch what happens here.
Okay, so you see that this code here was just added.
And down here is also this small summary.
So you see, there were six modifications,
five additions, so five lines were added,
and one line was deleted.
And now just to make sure that our working tree
is still clean,
so that we don't have to commit anything,
let's again watch git status.
And you see there is nothing to commit,
the working tree is clean.
And so the code that we have in this branch,
so in the master branch,
is now the same as in the new feature branch.
Okay, so this is a great feature to basically build code,
but without affecting our original code,
which might break with the changes that we are introducing.
And so usually, we never work in the master branch,
and simply add features in a different new branch.
And then once we're done,
we merge these two branches together.
And then if there is some error, or something not working,
we can always go back to what it was before.
All right, and that's all I had to show you
in this short introduction to Git.
And if you want to learn even more,
or maybe have all of these commands that I just showed you,
in one nice overview,
there's actually a very handy cheat sheet forget,
that was developed by GitHub, which I really like to use.
So let's search for GitHub,
Git Cheat Sheet.
Okay, and this one is probably it.
This one looks a bit different than the one I mean.
Yeah, this is the one that I have.
And actually, when I first found this,
I even printed this out and put it on my desk,
because there's a lot of stuff that we can do.
So here is what I just showed you with the branches, right?
Then here is Git status, Git add, Git init.
And, yeah, also Git reset-hard.
And so you see, there is a lot of stuff that we can do.
And in the next video,
we will then actually use these commands here.
So Git push and Git pull,
so that we can basically copy
our local repository onto a repository
that lives in the cloud on GitHub.
And this will then allow us to basically keep a backup
of our repository online.
And it will also enable us to automatically deploy
or site from this repository
by setting up continuous integration on Netlify.
And so let's learn how to do that.
So how to push our code to GitHub right in the next lecture.