 So, we are going to talk about version control system what they are specifically we are going to look at a version control system called gate these slides are not mine I found these on the internet. So, just Google gate tutorial the first couple of links will read you to these slides. So, actually I planned for a tutorial earlier, but there is some problem with a VGA connector. So, the tutorial is not going to be there I will give you an overview of what gate and gate hub is how does it work and why version control is important all these sort of things. By the way how many of you have already used this kind of thing like sdn gate data before a lot of you cool basically while you guys will start working you will need some version control system in order to sync your project across all the developers. So, you will install gate there are other version control systems as well, but we are going to use gate. Gate hub is basically a service which hosts your repositories which hosts your code. So, basically version control is something which keeps track of your code. So, if four people are working across a project and four people are situated at different different places there is a huge problem in syncing your code. Yeah. So, using version control systems we basically sync our code keep track of our code we can roll back to the previous stable state we can add more commits all this sort of thing. This commits staging area all these things all these terms which I am saying you are going to look at what these things are. So, gate is basically a distributed version control system created by Linus Torvalds the Linux founder. What happens is you work on your local repository make all the changes commit your changes and then you push your changes to the remote server so that everyone will be able to see and how you do it is internally managed by gate so that everyone is on the same page everyone has the same code and there are no like in there is no in sync changes. So, there are other version control systems as well like subversion purpose there is Tortoys SVN also, but like gate is like sort of the most popular stuff. So, basically what we are going to do during the course of this summer internship is you are going to create a one repository for your project on gate hub you are going to clone it clone it basically means copying it to your local directory you are going to start working in your local directory add all the changes that you are doing on a daily basis and then push your code on daily basis. So, when I say I commit my code I basically mean I am creating a snapshot of what I have right now a snapshot is basically the state of project right now. So, let's say I just created a empty folder I created one file in it with just print hello world nothing else so here so this hello world this one file is the first change I did in my project how others are going to know that I have made this change is I am going to commit these changes in my local repository first then I am going to push this changes to remote server. So, all this process is called committing like you are committing your code you are making your code final. So, commits are basically maintained in a sort of linked list sort of structure. So, after one commit there will be another commit another commit another commit and each commit will point to its parent commit repositories as I have said is just your project directories. So, what happens is first you create your repo on the gate hub and then you are going to clone that repo by cloning I mean you make a local copy of your repository on your laptops and you will start working from that. Okay another thing is a polling and pushing so polling changes means suppose you are working on one file another person is working on some another file or the same file some other different portions of the same file. So, once you start working before start before you start working you pull the changes of all the people then you start writing your code. So that your repository will be in sync another thing is after you make all the changes you are sure that your changes are fine it is working and after you commit your code you push all these changes to remote server branches. So, the general convention is to use different different branches for different features. The main branch is called the master branch I mean you can name it anything else but then people use this name master. This is basically the stable branch which works another branch can be a development branch can be another feature branch so that you just create a new feature add a branch after you are sure that it is working fine you just merge it into the master branch. So, this is how your your project is going to look like basically a directory where all the all your code will be there and a bunch of commits. So, as I have said commits are nothing but sort of a linkless kind of structure. So, this commit is pointing to its parent commit this commit is pointing to its parent commit this commit is pointing to its parent commit and currently you are here. So, head determines the position where you are actually right now and master is basically the branch name. So, you are at the head of your master branch. Yes, as I have said the main branch is called master but this is just a convention you can almost name it anything else. So, if you want to add new features you are gonna you are just gonna create a new feature branch code all your changes that you want to incorporate in your feature and then there is something called as pull request you create a pull request from your feature branch if the code gets verified it is working fine then your feature will be merged into the master branch. So, all this merging process this is this happens through something called as pull request initially we thought of giving you a demo of all that but then that that is not happening right now. So, we will see if sometime in the future we can do all these things. So, suppose your project is here right now and from here you decided to create a new feature. So, you will create a new branch called a feature branch you will start working on your feature and meanwhile the master some other features will be getting merged into the master branch. So, the master branch will keep on moving forward and after this commits let's say you realize that your feature is complete it is working fine. So, after you reach this point after you commit all your changes from here you will create a pull request and if it gets verified it will merge into the it gets merged into the master branch. Yeah, so your master branch was here earlier and if all these things gets verified this will be merged. So, the local copies of your project in your laptops in your desktop is basically called as working directory. After you make changes you need to move your files to the staging area before you can push them to the remote server. So, this intermediate layer is called the staging area where you add all those files using git add all these files will move to staging area then after that you commit your changes. So, these commits will be in your local repository after this step and then after that you can push to the remote server. So, as I said you use the command git add to put all your files into the staging area and then after that you use git commit to commit your new changes. And every commit has a specific message regarding what this commit is doing like what changes this commit is making. So, this is your working directory after you make all the changes you move your files to the staging area and after that you commit the changes and then the structure moves forward. You are here right. So, after you put your files to staging area and after you commit the changes your head will also move forward because head always points to the latest commit. So, what is GitHub? GitHub is basically a service which allows you to host your repositories. So, it has a very good bug tracking system, issue tracking system. So, what we are going to do is we are going to follow like issue driven development sort of stuff what basically issue driven development means is before you start writing code you create one issue which describes whatever you are going to do. So, even before you start writing a function that just prints hello world you are going to create one issue on GitHub which says this function is needed which prints hello world and your code will correspond to this issue. So, every time you push your changes you know that which issue you are tracking which feature you are tracking right now. Yeah, apart from all these all this stuff there is one very small course on Udacity. So, people who are like completely new to version control completely new to what gate and GitHub is just search for a course on Udacity just type gate course Udacity course or something like that is a very short course you can probably finish it in 5, 6 hours, but it gives you like all the details. I have talked about gate and GitHub on like very very basic level there are something called as merge conflicts there is something called as rebasing all these things will be available in detail in that course. Like over the course of time you will know how these things are done that's it.