Version Control - ybouz2/project-tech GitHub Wiki
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. Version Control has the abbreviation VCS, and is wise to use. Using a VCS means that if you do something wrong, run in to trouble or lose files, you can easily recover it by falling back to an earlier version.
Local Version Control Systems
A common way of version control is by copying files to another folder. Many do this because it is so simple, but it can also lead to errors very quickly. It's pretty easy to forget what folder you're in and accidentally put files in the wrong folder, or rewrite files you didn't want overwritten. To overcome these problems, programmers some time develop a local VCSs, which had a simple database that kept track of all changes of files under revision. One of the most popular VCSs was a system called RCS. RCS is a set of UNIX commands that allow multiple users to develop and maintain program code or documents. With RCS, users can make their own revisions of a document, commit changes, and merge them. RCS was originally developed for programs but is also useful for text documents or configuration files that are frequently revised.
Centralized Version Control Systems
The next big problem people ran into was having to collaborate with other developers on other systems. To counter this problem, Centralized Version Control Systems (CVCSs) were designed. These systems 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 some extent what everyone on the project is doing. Administrators have control over who can do what, and it's much easier to manage a CVCS than to deal with local databases on each client. Bu also this setup has serious drawbacks. The most obvious is that when the server goes down, nobody can do anything for a certain amount of time and nothing can be saved. Another point is that if the hard drive where the central database resides gets corrupted and no proper backups are kept, you literally lose everything. Local VCSs experience these same problems, if your entire history of a project is in one place, there is a chance that you will lose everything.
Distributed Version Control Systems
This is where Distributed Version Control Systems (DVCSs) come into play. In a DVCS (like Git), clients can't just get the latest snapshot of the files, but mirror the entire repository, including its entire history. So, if a server goes down and the collaboration went entirely through that server, each of the client's repositories can be copied to the server for recovery. So each clone is actually a full backup of all data. Plus, many of these systems are pretty good at having different external repositories to work with, allowing you to collaborate with different groups of people at the same time in different ways within the same project. Allows you to set up different types of workflows that are not possible in CVCSs, such as hierarchical models
Source: git-scm.com