A version control system, to a great extent, is based around the concept of tracking changes that happen within a collection of directories or files.

A version control system (VCS) allows you to track the history of a collection of files. It supports creating different versions of this collection where each version captures a snapshot of the files at a certain point in time and the VCS allows you to switch between these versions as well. These versions are stored in a specific place, typically called a repository.

The process of creating different versions (snapshots) in the repository is depicted in the following infographic. Please note that this picture fits primarily with Git. Other version control systems like Concurrent Versions System (CVS) don’t create snapshots of the files but store file deltas.

Importance of the version control system

There are many benefits of using a version control system for your project.

1. Collaboration: – With a VCS in place, everybody in a team has the freedom to introduce modifications to the files at any time, without being liable to the team members. The VCS will later allow you to merge all the changes into a common version.
2. Storing Versions: – A VCS acknowledges that there is only one project, therefore, there’s only one version on your desk that is currently being worked on. Everything else, all the past versions and variants are neatly packed up. When a need arises for an older version, you can request it at any time and you’ll have a snapshot of the complete project right at hand.
3. Restoring Previous Versions: – VCS accommodates the restoration of previous versions of a file or even the whole project.
4. Backup: – Using Distributed VCS like GIT allows us to back up our work.

Types of version control system

There are three most popular version control system.

1. Local Version Control Systems
2. Centralized Version Control Systems
3. Distributed Version Control Systems

1. Local Version Control Systems: –  A lot of people tend to employ their own method of version-control i.e. to copy files into another directory. This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to the files under revision control.

One of the more popular VCS tools is a system called RCS, which is still distributed with many computers. Even the popular Mac OS X operating system includes RCS. RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can later re-create older versions of the files at any point in time by adding up all the patches.

2. Centralized Version Control Systems: – The next major issue that people encounter is while collaborating with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) was developed. These systems, 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. For many years, this has been the standard for version control.

This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have 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 for every client.
However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the drive in which the central database is present, becomes corrupted, and proper backups haven’t been kept, absolutely everything gets lost– the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem “ whenever you have the entire history of the project in a single place, you risk losing everything.

3. Distributed Version Control Systems: – This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar, or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, 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.
Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.