Let us consider why we need revision control systems. As you work on a project, you make changes. They accumulate, you fix bugs, you add new features, you optimize. Eventually, your codebase looks quite different than your starting point. Sometimes, however, you add a feature, you fix a bug, you make an enhancement, you think everything is better, but then, it turns out reality intervenes. A user, maybe even it's yourself, finds that your application has problems. It could be just it's used in a way that you didn't think about. You could hit an impossibly rare race conditions when you did not think about, when you're working on a simple computer, but when you get out faster hardware and you have multiple processors, more things can happen. Then, you may have to say, ''Boy, I have to go back to an earlier stage, where things were still working and then, find the point in the development where things went wrong, so I can fix the problem." This can actually be a rather difficult thing to do, to find out exactly when things went wrong. Now, we've all used manual revision control methods. To do this, we can keep frequent backups of our work, for example, but it's nice to have some clean Intelligent Design, which can make this task much easier. So, if you're comparing your codebase with what it was at an earlier time, why not actually store the history of the changes, instead of just the earlier snapshot with the current one. Also, you can track the changes directly instead of just getting them by comparing endpoint to starting point. As you add other people to the project and you're not the only developer, the manual method becomes very difficult, because you have to annoint somebody as the master who handles all the actual changes, other developers will probably have to feed changes to that master developer, if you don't want to get too confused, and it becomes difficult to manage simultaneous contributions by more than one person. If you have distributed development to the extreme with a project, such as the Linux kernel, with thousands of developers all over the world working simultaneously on some of the same parts of the kernel and sometimes other parts of the kernel, even this notion of a central master repository of all wisdom starts to not make sense anymore. So, there are many different schemes available for source control. As we are discussing here, git is the one used by the Linux kernel, but also millions of other projects as has been shown by the growth of GitHub and there are many standard features of revision control programs, such as being able to keep an accurate history, a lot of changes to be able to go back to early releases, coordinate conflicting updates from more than one developer, etc. These are some of the topics we're going to talk about in great detail as we continue.