So with the installation out of the way,
we can now dive into Git.
Before we do that though, one last theory slide,
because I want to make sure that whilst working with Git
and while it's getting started,
that you are already aware of some of the core terms
that you have to understand to, well,
easily work with Git.
For this, let's think about a project
which is managed by Git.
In a Git-managed project
you have two separate areas, so to say.
One area, and that's the very important one
for you as developer, is the so-called working directory.
Your working directory is the current project folder,
meaning all the current folders and files
you are actively working on.
So basically, the code version you interact with
at the moment, where you implement changes and so on.
That's one side of a Git-managed project.
Now the active tracking part,
so this part where Git is able to save different
code snapshots and to track these changes,
doesn't take place in this working directory.
This takes place in the so-called repository.
This repository is a hidden folder, actually a hidden area,
which you cannot actively see.
But in this repositories,
we have all tracked files and folders,
meaning all files and folders Git manages for us.
Now, and from a conceptual perspective,
if you add a specific file to this repository,
we'll see how this works soon,
and therefore tell Git,
"Hey, please track changes I made to this file",
then Git doesn't save again and again copies of that file
if you, well, create a new code version
that you want to save.
Git only stores the first version of this file,
and then just tracks changes.
So it compares the current state with the latest state,
and then says, "Okay, this is what you've changed
so I have to keep this in mind
if you want to work on this latest code snapshot."
All some things will explore throughout this module,
nevertheless, the idea of how Git manages all the
tracked files and folders in this repositories,
is based on the concept of commits.
A commit is a single code snapshot and branches.
Branches are where commits are stored, so to say.
For example, thinking about such a commit,
let's say you are in your working directory,
you've changed something on some files,
you are working in your working directory,
and you added an image.
Then you would also add such a commit message.
So a message attached to this latest snapshot of the code
you want to save and call it, well, "added image".
With that, you and other developers are aware
of what you changed in this snapshot that you want to save.
Another code snapshot you want to save
could be something like "fixed order button" here,
for example. So basically whenever you change something,
whenever you fix the bug, whenever you added a new feature,
you create a new commit,
a new code snapshot with such a commit message.
And these commits are not somewhere saved
in this repository.
Each of these commits represents a single-code snapshots
you can jump back to if you want to.
And these snapshots are typically stored in the so-called
main or master branch.
That's so to say the core location,
the core area where your main project is saved.
So if you're working on a website
and you have the latest state of your deployed website,
then this would be the latest commit,
the latest snapshot in the so-called master branch.
Assuming that you want to improve things
on this master branch though,
for example adding such an order button,
then you could create a new branch,
for example feature branch,
which then holds this updated code snapshot.
And once this feature is finally finished
and checked for box and so on,
then you could bring this feature
also back to this master branch.
That's a bit more advanced at this stage though,
but this is how Git works in a nutshell with the core terms.
So working directory, repository, commits, and branches.
With the theory out of the way though,
let's now finally dive into Git.