Nowadays, Git is a very important technology that we all need to know irrespective of the technology we are working on. Now you may be wondering why the title is on Version Control System whereas the tutorial is on Git. Actually, Git itself is a type of Version Control System.
Now,
What is Version Control System?
As the name suggests Version Control System refers to a system controlling some versions. In technical terms, Version Control Systems are software that helps you to track changes that you make in a code over time.
And
Why do we need it?
Scenario 1 (the most common one):
You are working on a project in a team where you and another team member are working on the same code and you depend on your team member's code. Now, how are you going to get his/her part of the code? Are you going to visit him/her and then get the code? Let's say you got it that way but what if it's a bigger project and many people are working on it, so if you need their code, are you going to visit each of them? and what if they are all in a different location? It sounds very tedious right and unreliable solution.
Scenario 2:
You are working on a project and you are trying to add some new features or update some old features. But after changes, your code broke and you now desperately want to move back to the older version of your code. Now you may say "okay I changed the code right, so what? I know how to write it again" but what if the changes you made are so big that you can't remember what exactly you did before and you can't memorize everything every time in a big project.
Scenario 3:
You are working on a live project and want to add some new features without interrupting the main project. What will you do then, will you copy the entire project into your local system and then start coding on the new feature?
These are some real-world problems and you will face at least one of them in your entire career. That's when some genius minds built Version Control System.
How does it work?
In the version control system, the code is hosted on the internet so everyone can access the code and the place where the code is stored is called Repository or Remote Repository.
So, your main code or project will be hosted in the remote repository and if you want to edit the code or some part of the code you need to fetch the code from the remote repository to your local machine. After you've made your changes, push them back to the remote repository so that the next developer who relies on your code can get it and update their code accordingly.
There are other functionalities as well, like checking out who made what kind of changes (commit) in the project or if you want to add extra functionality or features without touching the main code (source code), you can do that as well (by creating branches). It is also possible to revert to the previous versions of your code whenever you want. There are numerous advantages that you can obtain, which we will discuss in detail in the upcoming tutorials.
Some important terminology:
commit: Record changes to the repository or save points or checkpoints.
branch: Creating a copy of the main code from the main line of development (main branch) and continuing to do work without messing with that main line.
merge: Combine two or more development histories.
push: Uploading local repository contents to the remote repository
pull: Fetching data from the remote repository and updating the local repository
revert: Rolling back to any existing commits
Types of Version Control Systems(VCS):
Local Version Control System or LVCS
Centralized Version Control System or CVCS
Distributed Version Control System or DVCS
Local Version Control System (LVCS)
This is the simplest form of version control and was primarily used by solo developers. All the project data is stored in a database and the changes made to the files are stored under revision control. Revision Control System or RCS is an early implementation of VCS which is a set of UNIX commands that allow multiple users to develop and maintain program code or documents. RCS works by storing patch sets (the differences between files) on the disk in a special format. Each patch includes the updates that have been implemented since the previous patch. It can then add up all the patches to recreate what any file looked like at any point in time. To diagnose an issue with a specific version of your project, you must go through the entire collection of patches to piece together what the project files looked like at a specific point in time.
Centralized Version Control System (CVCS)
As Local Version Control System focuses on solo developers that's when developers developed Centralized Control System where other developers can also collaborate. This type of VCS has one global repository that contains all the versioned files and if any changes or updates are made to the main code, it will be automatically stored as a new version and everyone can know about the changes or updates, which is an advantage as everyone has the idea of what is going on in the project. This type of VCS uses a check-in/push workflow and has branching and merging capabilities. It has a file-locking mechanism that means only one developer can contribute to the code at a time. Team members use branches to contribute to the central repository, and the server will unlock files after merges.
But the main downfall is the single point of failure means if the server goes down, no one can work on the code or push changes. Another downfall is if the hard disk of the central database becomes corrupted, and proper backups haven’t been kept, you lose everything. Only the snapshots on local machines are retrievable. That's when the developer moved to Distributed Version Control System.
Some popular CVCSs are Apache Subversion (SVN), Concurrent Versions System (CVS), Perforce etc.
Distributed Version Control System (DVCS)
In the Distributed Version Control System or DVCS, every team member has access to a local copy of the entire repository, including its full history on individual hard drives. Here, developers can commit, merge and create branches locally. So, your changes will not reflect on the remote repository unless you push those changes first. Similarly, if others made some changes in the remote repository and you want those changes then you have to pull those changes first into your repository.
Here, everything is on your local system so even if the server is down or the network is slow that cannot affect one's work. Multiple people can work simultaneously on a single project. You can work on and edit your copy of the files and choose when to share your changes with the rest of the team, which gives developers more flexibility and increase their productivity.
Some popular DVCSs are Git, Mercurial, Bazaar etc. The first open-source DVCS were Arch, Monotone, and Darcs. However, open-source DVCSs were never very popular until the release of Git and Mercurial.
So you may now have a good understanding of VCS. What is Git will be covered in the upcoming tutorial. So keep an eye out for the next one.
Previous: Git For Everyone: A Comprehensive Guide
Next: What is Git