Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. 
It allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue, when, and more.

Local Version Control

Many people’s version-control method of choice is to copy files into another directory using timestamped directory. It's a very common approach because of its simplicity, but it is also incredibly error-prone. Because it's easy to forget which directory you're in and editing files.
To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
The next major issue that people encounter is that they need to collaborate with developers on other systems.

Centralized Version Control

To overcome local repository problems, Centralized Version Control Systems (CVCSs)  were developed.
The system such as CVS, Subversion, and Perforce have a single server that contains all the versioned files and a number of clients that check out files from that central place.
With this setup, everyone knows to a certain degree what everyone else on the project is doing. Fine-grained control over who can do what, and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
The problem associated with this setup, the most obvious is the single point of failure that the centralized server represents. If the hard disk of the central repository is corrupted, and proper backups haven’t been kept, you lose absolutely everything.

Distributed Version Control 

Due to single point failure in centralized version control, this is Distributed Version Control System steps in.
The system such as Git, Mercurial provides a distributed version control.
Clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.