So we saw lots of good terms and fury now let's now apply.
Get in practice.
And for this, we first will create a new folder.
In my case, I'll create it here on the desktop.
So we'll create a new one and let's call this folder,
get basics.
Now we need a new visual studio code instance,
a new visual studio code window, which I got right here.
And now I'll simply drag this folder into VS code. Yes,
we trust the offers and we can close this welcome screen and
also maximize we VS code.
So now we are inside vs. Code, nothing new to you.
And in a year we could, for example,
we'll create a new file and call it well,
simply test dot text, just to get started.
As I said, at the beginning of this module,
this is a web of course.
So we will look at it from a web developer perspective,
but we can use skit to basically track will anything.
This could be CSS files, JavaScript files, HTML files.
This could be text files, XL files.
So basically anything therefore here in this module,
I'll mainly focus on two text files because it's all about
this skit file tracking logic that we have to understand.
If you apply this logic then to code protects files or
anything else, doesn't play a big role.
Still.
We keep it generally inside the web development world.
Therefore we can add this test dot text file,
and then there, I could now add something.
This is my first commit. For example,
you learned in the fury module that a commit is basically a
code snapshot. Let me maybe make this a bit bigger for you.
Okay? So let's save this and now I want to manage this code.
This text file via get,
and this should be stored as snapshot at the moment.
This is just a safe text file on the machine,
which doesn't help me too much to use it.
Now we need to use the terminal or do command prompt on
windows and envious code. We have a great feature,
which is an implemented terminal.
This is something we as code chips with by default.
And you can find us if you go to view appearance and then in
here show panel, if we click onto this, right,
maybe make it a little bit smaller like that.
Then you see that down here,
we have the integrated terminal and this terminal
automatically navigates into this folder. You see,
get basics is the folder name we used here.
Now in this terminal,
you can see that we have here on the Mac D shell activated.
You can this over here and here,
you could also switch to another shell. For example,
the Basher,
then you won't be able to switch between these two shelves
by clicking right here or right there.
We'll just use these that shell in here or the command
prompt on windows.
So windows users please select the CMD here.
And therefore we can select the other one by clicking onto
this weld trash icon.
With that,
we have to integrate a terminal navigated into D current
folder here and now I want to manage this first text file
while I get for this, we have to initialize our repository.
You remember from the free slide that we have a working
directory, which would be our text pile and a repository,
which would be the tracking part git internally does.
And to bring both of these things to life,
we have to initialize a good repository.
We have to initialize the skid project.
This works with a git command and just S get dash dash
version. We also have to add,
git first to tell our machine,
that we want to run a git command
And the command to initialize a repository is simply get in
it with this in place and confirmed with enter.
You get some hints here about the naming convention of the
master branch. I explained that on the fury slide,
the master branch is basically the core location of all our
code snapshots of all our commits.
By default, this branch is called master nowadays.
We also use main for the master branch, for example,
and if we want to,
we could rename this branch with this command here,
get branch dash M and then apply a new name.
We'll dive into renaming branches a bit later in this module
when we understood what branches are in detail.
Therefore, the only thing we have to do right now is, well,
basically nothing.
We can just continue by adding our first commit.
Now for this I'll first clear my terminals on here to add
more space and we can also drag this up a bit and now we can
run another good command to see that this is a project
managed by git now. And this command is called, get status,
with git status.
We see well information about our current git project.
We see that we are in the so-called master branch.
As I said,
this is something we'll explore a bit later in this module.
We don't have any commits yet.
So we don't have any code snapshot saved at this stage.
And we have untracked files.
Now, what is this now?
Well git, it's all about file tracking and tracking changes.
I just told you in the fury lecture that if you add a file
to a certain committee the first time. So in our case,
if this text file should become part of our first code
snapshot that we store,
then we first have to tell it that this file and changes of
this file should be tracked.
And afterwards the snapshot can be saved.
The idea behind that is that, well, you first have to tell,
good, please include this, this and that file.
For example, in my next code snapshot,
and then save the code snapshot because you might want to
exclude some files or some changes of some files in their
specific snapshot.
Therefore you can explicitly tell it which files should be
tracked and therefore,
which are eligible to become part of the next code snapshot.
Now, this sounds a bit strange at this stage,
but if we now simply run, git, add,
and now refer to the file that we want to add the fly that
should be tracked.
Then we can simply add git add test dot.text by running this
command enter, you see nothing changes at first sight,
but now this file is a tracked file.
And therefore this file was added to the so-called staging
area.
The staging area is the area Birgit sees.
The developer wants to include this file or changes applied
to this file in the next snapshot. That should be stored.
That's basically the staging area.
So it's in between our working directory and the commit that
we want to create.
If we run git status, once again like this, you'll see,
we basically have the same information that we saw before we
are in the master branch. We don't have any commits yet,
but now we have changes to be committed.
And now this red file name here became green because now git
tracks. This file and change is applied to this file.
And therefore we can now add this file to our first
snapshot.
Let me clear this now.
And let's now create this first snapshot. And as I said,
snapshots and get are called commits.
Therefore we can not run, git commit.
And now dash M this will simply allow us to add this commit
message. I also showed you on the fury slide.
So here in quotation marks,
we now add what we changed or what we did to this file.
In our case, we can simply say added test.text file,
for example, and with enter,
we can run this command and then we get some additional
information here.
If you never worked with git before,
then you should specify the user name and the user.
Email of the person that created this commit.
If you're working alone on your project,
this doesn't make a very big difference.
But if you collaborate on a bigger project, for example,
on GitHub, which we'll explore a bit later in this module,
then it's crucial to see who created a specific commit who
changed the code otherwise? Well,
if everybody could just add commits,
could just change the code without adding any kind of hint
who did that. Well, this would lead to big chaos.
Therefore it's important to add our credentials here.
You can also find a command in here.
The git config dash dash global dash dash edit command.
And we can also run this together now.
And in here, you cannot see, well, in my case,
two types of information at the bottom below this,
please adapt an uncommon to following lines.
You can see the default name and email that get created for
my computer,
for my user account here above you can see my individual
configuration that I added. So manual Lawrence,
and then this dummy@academy.com email address.
Now editing the credentials in here is generally possible,
but we are using the wrong editor at the moment.
We would have to link well, this part of git.
So to say to we as code in our case, to be able to add it,
the credentials in here, we have another option though,
to add it, our name and email,
therefore we'll first leave this menu with escape, colon,
and X. This seems to be a bit awkward,
but it's the well default key combination to access this
menu. So escape, colon and X, by confirming this with enter,
we are back in the terminal.
You can ignore the fact that the information about the
credentials is no longer displayed in my case here,
because we talked about this already.
What's important now, though,
is that we can individually access the username and the user
email, and also edit it.
We can do this with another good command and this command is
git config. As we just had it before,
this allows us to change the git configuration in our case
to git user configuration.
Then we again enter dash dash global global here simply
means that the credentials I add now,
or I added now are added for this user account on all good
projects on this computer.
You could also set credentials for all users on a machine.
For example,
typically that global user on a specific machine is the way
to go though. And now our space,
and now we enter user.name with this. If we just hit enter,
we see the current username that is added in Mike has manual
Lawrence, or if you want to change it, you could just run,
git config dash dash global user.name again,
and now in quotation marks,
because if you want to add a first and a second name,
like in my case manual Lawrence,
which won't make a difference obviously, but with this,
we could update the username here. So let's do this.
And now besides the username,
we should also check or edit it. Our user email.
It's basically the same git command here.
We use git config dash dash global,
and now user.email here.
You can now add the email address that should be displayed
in your commits.
You can do this within or without quotation marks.
I'll add the email address also inside quotation marks here
and there are used well dummy@academy.com.
Make sure to use your own individual email here, though,
with this. If we run the command, once again,
without the email address added at the end,
we should see that now this updated email is this displayed.
So these are our credentials now,
but what about this commit this code snapshot now.
Well,
let me clear this again and to see whether a commit was
created successfully while we have two options,
the first option would be to, again, run,
git status in here.
There we see you. We have nothing to commit.
Our working tree is clean. This means, well,
somehow our snapshot was saved. Obviously, besides that,
we also have another command git log,
which gives us an overview of all commits inside our master
branch. Here with this command,
we can see that the commit was created successfully.
And by the way, with the initial credentials you had,
in my case,
I just showed you how you can change the credentials,
but the credentials were the same. So in your case,
you should see your initial credentials that get added by
default.
Now being creating another commit.
You should see the updated credentials.
We'll do this in a few seconds in here.
You can also see some additional information.
The first one here is this commit ID.
Each single commit you create and git has a unique ID,
which allows you to exactly identify this specific commit.
Here. We have to offer information.
We talked about this already here.
We have the date when this commit was created.
And down here,
we have the commit message that we added when saving that
code snapshot.
So this is our first commit and also our edited credentials.
Now we could also create another commit and another code
snapshot for this I'll stay within the file.
So within the track file that we had to,
well add some text in here, let's say,
and here we go with commit number
two, for example.
And besides this,
don't forget to save this in here besides this.
I will not also create another text file and call it maybe
second commit dot text, and I'll keep it empty.
It's just about creating this new text file.
And if we now, again, run, git status in here,
then you see, well, two different types of information.
First, you see that we have changes,
not staged for the commit.
And there you can also find which changes.
This refers to it refers to the modifications in our tracked
file,
because with adding our test dot text file to the staging
area, as part of our first commit, we kind of told,
git that well,
it should monitor this file and change as applied to this
file because the other information we have is, again,
this untracked files information,
which now refers to this newly created file.
Second commit dot text was not part of the first commit.
Therefore get tells us, Hey, you edit a new file.
What about this file? Should I add this to the staging area?
And therefore also track this file.
And later on change as applied to this file,
we want to include both of these changes in our next
snapshot. And for this, we have two options.
Now, the first option would be to again, run git add.
And now we refer to the first file. So test.txt,
test.txt with the updated information,
then a space and then the second file name.
So second commit dot text.
This would be possible and totally valid,
but in cases where you added multiple files and name changes
to other files, well, this can be a bit cumbersome.
Therefore we have a command to add all untracked files to
the staging area,
and to also add all changes made to track files to the
staging area. This command is simply git add now a space,
and now a dot, why running this command?
We can now add a commit message. So you run again,
get commit dash M for example,
changed test dot txt and added second
commit dot txt.
If we run this,
we see behalf two files changed and by again,
checking our statues, you'll see everything is all right.
And by checking our commit log, once again,
we see that we now have two commits again with the commit
message and again, with, for new unique ID.
So this is how you can initialize a good repository,
how you can change your credentials and how you can create
commits inside such a repository.
And also inside a specific branch.
We talked about branches on the slide already. And in here,
we are always on this master branch,
therefore with the basics about commits out of the way,
let's now dive into this branches topic.