Okay, in this segment, we're going to talk about managing code and the use of revision control systems for this process. And we're interested here in projects that involved multiple people and where the complexities of a certain level. And revision control systems are the primary tools to handle large amounts of code and keep them in sync. So let's give you a brief history of revision control systems. Revision control systems involve a system that stores previous version of the code and allows comparisons with newer versions. And involves inducing what's changed and all those good things. They can be their local that lives on your local file system or they can be server based. The original division control system is coming called SCCS, source code control system and this goes all the way back to 1972. So if you remember that computer science as a field probably starts in 1970 or software engineering. This is from the beginning, effectively of the process. The first commonly used to one or at least the first one I encounter is RCs revision control system. This started in 1982. This operates on one file at a time and it was still in use in the 90s. So you would have a file main.c that so far you're working on and in the same director you'd find a file main.c,v. We restore all the previous versions of the file to allow you to go back and forth. It was a different controls stream for each file. This was a file based system. CVS concurrent version system, this came out in the late 80s. And this was the first whole project system and it was server based and this is where large multi program a software systems based in different locations started using this. And that was the beginning of that process. And then Subversion this start around 2000 and this was the most common system until about 2015. This fix many of the problems with CVS and it was the first really user friendly revision control system that known for expert programmers could actually use. But the reality is that the winner now the most common one is Git s a distributed repository. He was developed originally for the needs of the Linux kernel which is probably the largest open source project out there. It was developed for speed. It has a simple design. It's fully distributed, meaning that the local computer and the server all have equal copies of the entire system and it can handle large projects efficiently. And one of the big things about Git is that has strong support for nonlinear development. This is thousands of parallel branches and this is what it really shines and we'll talk about branching in the next slide. For those of you are not familiar with Git. There are many books on Git, one of them is this book by to construct called pro Git that you can find online and is well recommended. So what do you mean by branches? This is one of the most important parts of Git. Let's say you have the main branches where the code is and we're working along each box represents another version of the software a day later, a week later, a month later, depending on your timeline. And now you need to make some dramatic change, some major feature revision. You create a branch of branches, a copy of the code. So the purple thing is now a copy of the code. You work on the brush and you implement the new feature that you want to implement. In the meantime, your colleagues are working on the main brush and they are new features as well. And at some point we merge back, we take our changes and we merge them back into the main branch. And this sort of re incorporates the work we did on the side branch into the main floor of the program. At which point the branch gets deleted. Now, somebody else at the same time, we have created another branch. They wanted to work on a different aspect of the code they kept working on it and some time later that second branch. Let's at bluish branch also gets measured to the main and this is how Git works. We create branches, we work on a different feature, we merge them into the main and then we delete the branches and we keep going on. And the important lesson here is that any time we have a tool like this which is central to what you need like Git you want to master. You're going to get familiar with Git and learn how all these branching structures work and how you check for differences across branches. And how you do merge, those are all important things so one must know. Git and GitHub repair. Git is a softer from managing the repositories and GitHub.com is a service that provides repositories. And this is now owned by Microsoft office the last few years, there are other services gitlab for example that used the same principles. But we'll stick to GitHub for our description because it's by far the most popular and the most commonly used. So let me give you a short primary Git for those of you not familiar with it. Git you can think of it as something like dropbox on steroids. It allows you to share files and their revisions and to go back and have different versions and to merge versions and do all those good things. The server has the official repository at least that's the nominal as a policy. There's nothing in the software, the mandates that but the official copy is usually the one that's on the survey. You create a copy or a clone of that repository. You work on your machine make changes and commit them to your clone and then you synchronize your clone with the server. That is the basic process. So let's look at the same thing in flow chart format. This is your work flow on the left we have the cloud, this lighter color background and on the right we have your computer. There's a slightly darker background. We have a repository on a server perhaps github.com. We have a local repository on your computer. This is the copy of the repository that lives on your computer and we have your local files that those are the ones you're editing changing working on. So, the process causes follows. First we clone we take the deposit and a complete copy on the local repository and you do this once when you start working on a project. And then we do a git pull and this happens regularly which is we synchronize the copy of the repository on the local repository. So we recently as a server to a local repository and to the local file systems. We have files that we can now work with edit. When we make changes and we are ready to send our changes upstream. We first add them and this puts them in a temporary local staging area on our computer. You had all the files. This happened one at a time, two at a time. And when you're ready we have something that sort of works. We committed to the local repository. This creates a new version of the software in the local repository, this is still local. You do multiple commits perhaps and then eventually you can push your code changes from your local repository back out to the server. Now all those words are commit, pull, push those are all good commands and this effectively what you would type in the system. And there are many tutorials and guidance documents to git. One that I like and one of my students found is this Git cheat sheet that comes from a web page called chair rebel and shows you all the good commands. For example, there's a Git diff that shows the difference between your current version of the current wasn't a repository. There is good log shows you the list of changes, there's a branch command that helps you work with branches. And there are other functionalities a lot of functional didn't Git and encourage you to become familiar with this if that's what your environment, uses. The final thing we're going to talk about in this segment is used. The use of GitHub as a collaboration environment is more than a place to store code is a place where we can collaborate. So one should probably never commit this is a good rule of them to the main or the master branch directly. You ensure that the main always had a working version and so we want to make changes. We create a branch work for a while. We commit regularly and when this is ready to create what's called a pull request. We say, okay, this branch is ready to be merged into the main then we ask a colleague or a supervisor that maybe policy near companies who do that, does the reviews. We make changes as needed and we re review, we respond to comments, a whole lot of commenting going back and forth. When this is ready, we merge the branch into the main branch and then we delete the branch because this was a temporary structure that we're now able to delete. And you should really make an effort to keep branches short lift. One of the things if you look at this process and you think a little bit this is very compatible with the quality management system. We have reviews, we have documentation, we ask people to read, we know who did what and there's a whole history of this process that's stored. And that's very compatible with operationally design controls in the creation automatically if you wish of a design history, file type situation for the code. Let's just look at the word example of how this would work in practice. Let's say, we have now issued a pull request. This is a request for changes for review. We can see and you can in a small phone here the red and the green or what change in the code. Let's zoom in here. Perhaps the original had the word set up 10 among the circle it here and then the change became set up 12. So now you can see what change in your code you can put them side by side. And now you can actually review that and submitted that a comment or an approval depending. So here I said this looks good because I have reviewed the court and it looks fine. So this is a good first. Here's another example here where if we zoom in a little bit again, this is what this looks good prisoners. But we could have added a comment here or we can request changes depending on what needs to happen. And then when you're all done and you can't read this form. But what I wanted to see just the list of all the things, these are all the comments, the details, somebody requests the code, somebody requested, changes, somebody reviewed it. Somebody approved and this is essentially the point of a curious as well. We have now this complete revision and approval system with dates and times as to who coded it, who reviewed it. Who made changes, who did the final approval? And this is a good way to do this and we have a record now for later only thing as needed. It's not necessarily full proof. I think there was two changes. The records is not permanent, but that's true of all kinds of records but it's a very useful way to go back and redo the history of the code. So this concludes our discussion of programming as such. In the next few segments will switch from programming to testing to actually running the code in testimony to make sure that it works. Thank you.
