But before jumping into the demo I would like
to give a high level overview of the GIT workflow,
which will help you better, following the demo. So let
me start by representing four fundamental elements in the GIT
workflow which are these four: the workspace which is your
local directory. The index, also called the stage, and we'll
see in a minute what the index is. Then, we
have the local repository. We'll also refer to this as
HEAD in the, when we explain the different commands
and then, the word flow. And finally, the remote repository.
If you consider a file in your work space it
can be in three possible states. It can be committed
which means that the data, the latest changes to the
file are safely stored here. It could be modified, which
is the case of the file being changed and no,
none of these changes being saved to the local repository
so locally modified or it can be staged. And
stage means that the file is basically part of this
index. And what that means, that it's been tagged
to be considered in the next commit. And I know
that this is not all 100% intuitive, so let's
look at that again by considering the actual workflow and
let's see what happens when you issue the different
commands in git. So the first command that you normally
run in case you, you're getting access to a remote
repository, is the git clone command. And the git clone,
followed by the url for that repository, will create a
local copy of the repository in your workspace. And of
course, you don't have to do this step if you're
creating the repository yourself. The next command that we already
saw is the command add. And what the command add
does is to add a file that is in the
workspace to this index. And we say that after that, the
file is staged. So it's marked to be committed, but not
yet committed. And here I'm just mentioning this minus u option.
If you specify the minus u option, you will also consider deleted
files File, but let's not get there for now, we'll talk
about that when we do the demo. As I said, if you
add the file, it just gets added to this index but
is not actually committed, so what you need to do, is to
commit the file, so when you execute git commit, all the
files that are staged, that are released it here, their changes
will be committed to the local repository. So your files, as
I was saying, they can be in three states. They will
go from the modified state to the stage state when you
execute the app. And then from the stage state to the
committed state when you perform a GIT Commit. Okay, so at
this point your changes are safely stored in the local repository.
Notice that you can also perform these two steps at
once by executing a Commit -a. So if you have
a set of modified files, and all these files are
already part of the repository, so they're already known to diversion
control system, you can simply execute a commit -a.
And what the commit -a command will do, it
will stage your file and then commit them. All at
once. So it's a convenient shortcut. Of course, as I said,
this will not work if the file is a new file.
So if a file is a new file, you have to manually add
it. Otherwise commit -a will just stage and commit at once.
As we discussed when we looked at the diffence between centralized
and decentralized version console system. We saw that in the case
of the decentralized, there is a local repository which is this one.
And then you have to explicitly push your changes to a remote
repository, and this is exactly what the git push command does. It pushes
your changes that are in the local repository to the remote repository
so at this point all of your changes will be
visible to anyone who has access to the remote repository.
Now, let's see the opposite flow so how does it
work when you're actually getting files from the repository instead
of committing files to the repository. So the first command
I want to mention is the get fetch command and
what the get fetch command does is to get files from
the remote repositories to your local repository, but not yet to
your working directory. And we will see what is the usefullness of
doing this operation. Of having the files all in the local respository,
but not in your local directory. So, what that means, just to
make sure that we're on the same page. Is that you
will not see these files when you workspace. You will still have
your local files here. So this is sort of a physical distinction.
In order to get your data files from the local repositories to
your workspace you have to issue another command. Which is
the command git merge. Git merge will take the changes in
local repository and get them to your local workspace. So at
this point your files will be updated. To what is in
the remote reposity. Or at least what was in the
remote reposity at the time of the fetch. SImilarly to what
happened for the add and commit. There's a shortcut which is
the command git pull. So in case you want to get
the changes directly. To your work space with a single
command, you can issue a git pull command and what will
happen, is that the changes will get collected from the
remote repository and they will go to your local repository and
to your work space, at once. So this has the
same affect as performing a git fetch and a git merge.
So if we can do everything in one command, why,
why we want to fetch and berch as two separate operations?
So one of the reason is because this allows us
to compare files before we actually get the latest version
of the files. In particular, I can run the command
git diff head to get the difference between my local files,
the files in my working directory, and the files in
my local repository. So what I can do, I can
fetch the files from the remote repository, and once I
fetch these files. I can run a git diff head and
check what the differences are. And based on the differences decide
whether I want to merge or not. So while we are talking about
git diff, there is something else that you can use with the
diff command. So what you can do, you can run git diff
without further specifying head. In this case, what the command tell you
is the difference between the files that you have in your work
space and the ones that are staged for a commit. So basically,
what it will be telling you, is that what you could still
add to the stage for the further commit, and that you
haven't already. So what local changes will not make it to the
next commit, basically. And this you can use, for example, as
a sanity check before doing a commit to make sure all the
local changes that you have, and that you want to commit,
are actually staged and therefore will be considered. So now we will
cover all of the commands that we saw here. In our practical
demo. But please feel free to refer back to this Git Workflow
to get a kind of a high level vision. Or maybe you want to keep it next to
you, because this really gives you the overall structure
and the overall view of what happens when you
run the different commands. And it also helps you
visualize The different elements that are relevant when you're
using GIT. So the workspace, once more, the index
or stage, the local repository, and the remote repository.