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.