Now that we have a Git repository, let's talk about the
basic Git workflow, what we do on a daily basis when using Git.
So here's our project directory. And here's our Git repository,
which is actually a hidden subdirectory in our project
directory. Now, every day, as part of working on various
tasks, we might find one or more flats. When our project reaches
a state we want to record, we commit those changes into our
repository. Creating a commit is like taking a snapshot of our
project. Now in git, we have a special area or a special
intermediate step that doesn't exist in most other version
control systems. It's called the staging area, or the index is
essentially what we're proposing for the next commit or the next
snapshot. So when we're done making changes, we add the
Modify files to the staging area or index, review our changes,
and if everything is good, then we'll make a commit. The
proposed snapshot will get permanently stored in our
repository. So the staging area allows us to review our work
before recording a snapshot. If some of the changes shouldn't be
recorded as part of the next snapshot, we can unstaged them
and commit them as part of another snapshot. That's the
basic Git workflow. Now, let me walk you through a real example.
This example is crucial. So pay close attention all the way to
the end. Even if you think you know the basics. Our project
directory is currently empty. So we add a couple of files here.
Now if you're ready to record this state, so we use the Add
command to add these files to the staging area. Now these
files are in the staging area. This is the state we're
proposing for the next commit, we review this file, everything
is good. So we use the commit command to permanently store
this snapshot in the repository. As part of this, we supply a
meaningful message to indicate what this snapshot represents.
This is essential for having a useful history. So as we fix
bugs, implement new features and refactor our code, we make
commits and each commit clearly explains the state of the
project. At that point in time, so now we have one commit in our
repository. Now a common misconception about Git is that
once we commit the changes the staging area becomes empty, this
is not correct. And I think this is why a lot of people find Git
confusing. So what we currently have in the staging area is the
same snapshot that we stored in the repository. So this staging
area is actually very similar to a staging environment we use
when releasing software to production. It's either a
reflection of what we currently have in production, or the next
version that's going to go in production. So let's continue
with our example. Let's say as part of fixing a bug, we make
some changes to file one. Note that what we currently have in
the staging area is the old version of file one, because we
haven't staged the changes yet. So once again, we use the Add
command to stage the changes. Now what we have in the staging
area is the same content we have in our working directory. So
let's make a commit to record this date. Now we have two
commits in our repository. Also ook at the commit message is
escribing the bug that we just f xed. Now let's say we realized t
at we no longer need file to i contains unused code. So we d
leted from our working d rectory, but this file is st
ll in the staging area. So on e again, we should use the Ad
command to stage this ch nge. I this case, the dele
ion. This is the inte esting part, even though we'r
saying Add File to get know that file to is actually dele
ed. So it will delete this file from the staging area or the
ext snapshot. And again, we make it commit to permanently re
ord this state. Now we have th ee commits in our repository. Ea
h commit contains a unique id ntifier that gets generated by
Git. It's like a revision nu ber h commit also contain
information about what was cha ged by who went as well as a co
plete snapshot of our project at the time it was created
So unlike many other version control systems, git doesn't
store the deltas or what was cha ged. It stores the full content
With this, Git can quickl restore the project to an ear
ier snapshot without having to compute the changes anyone
asked. But hey Marsh wouldn t storing the full conten
in every snapshot wastes a lot f space. No, because Git is ver
efficient in data storag . it compresses file conten
s, and doesn't store duplic te content or someone using
it, you don't really need to kno how Git stores data that's
implementation detail, and ma even change in the future
What you need to know is that e ch commit contains a comple
e snapshot of our projec . And this allows us to quickl
get back to the previous state. So that's the basic idea. Over t
e next few lessons, you're going to see this workfl
w in action.