[MUSIC] >> Let's go over some basic concepts associated with version control. I'll talk about the theory behind centralized version control systems, and then I'll go over the theory associated with the more recent distributed control systems. Even if you're a single developer, working on your own, you need some type of version control to keep track of the versions associated with the software you're developing. You may need this in order to back track to a previous version of your code, if you introduce an error that you can't track down after really breaking things. Or you may need it for other reasons. Let's take a look at how you might do this. You might have some type of version controlled database, which could be as simple as keeping versions within subdirectories on your local file system. Here, I show version one of a software system that has three files. Files A, B and C and in version two I show a file C prime. This is C Files C after being modified relative to each state version 1. Next on the left I show that the developer has checked out file A from version 2 made edits to the file and then, checks that file back in, in order to create version 3 of the software. And then this version files A and C had been modified relative to the first version. What I just showed you will work fine for a single developer. But it's not going to work very well for a team of developers who are all trying to work on a software system at the same time. Traditionally, version control has been managed by keeping a centralized version control system that team members would use to check code in to and out of A central repository is used so that developers can share files. You want developers to be able to work in parallel, but you need to make sure they're not writing over each other's work. The typical approach is to lock a file whenever it's checked out by a team member who then owns that file. Others can't modify the file until that current owner checks it back in. So here I show Developer 1. Checking out file A, this gets noted in the repository and Developer 2 is prevented from modifying file A during this time. During the time that is checked out the Developer 1. Developer 2 however can't check out and modify file B. How do these centralized version control systems work? Well they store differences. So they store the difference between Version 1 and Version 2 is only file C was changed so that delta is stored, Version 3 I show two deltas for file A and one for file B and so on and so forth, so this is how Centralized Version Control works, it only stores the differences between file as editor made.