Version Control is very important to make sure any change in the source code should be recorded and allow us to recall a specific version later. Imagine we edit some lines of code then deploy it without full-test then the error occurs due to the changes, unfortunately, we forgot to make a backup of the old code. Now how do we can revert to the previous version? In order to avoid these problems, we need a version control system to record and keep track of all changes in our code.
A version control system allows us to revert a selected file back to a previous version or revert the entire project. It also allows us to see who last modified and so on.
There are three common types of version control system we should know about:
- Local Version Control System
- Centralized Version Control System
- Distributed Version Control System
Local Version Control System
Many people always control the change for each file by making a copy of the file with a new name, especially for non-tech people. This approach is widespread because it is so simple, but it also has some backward such as error-prone, hard to remember all the path and the name of files. This approach keeps all changes in a single local computer so all the files might be lost if the disk broke and can not recover. A software call RCS is popular software that applies this approach.
The Revision Control System (RCS) manages multiple revisions of files. RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, including source code, programs, documentation, graphics, papers, and form letters.
Centralized Version Control System
With Local Version Control, we are very hard to collaborate with others to allow the collaboration, centralized version system was born.
In basic, we have a central VCS server to store all changes so anyone who has privileges can commit their change to the central server or pull other’s changes to their local computer.
However, this approach also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If the central server is unavailable for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on.
CVS, Subversion, and Perforce are relying on this approach.
Distributed Version Control System
To avoid the downsides of the Central Version Control System, the Distributed Version Control system steps in. In this approach, each client plays the role of mirror repository, including its full history since versioned. If the remote server crash, we able to restore from client’s local repository.
I write this articel following a book tittled ProGit
ProGit books: https://git-scm.com/book/en/v2