What is the purpose of a Version Control System in Web Development?

What is a Version Control System

Hello everyone, welcome back to the training. So today in this session we’re going to start with what is version control. So let’s go ahead and understand what is it exactly.

So, guys, version control is nothing but a system that manages the changes that you make in your code, right? So every time you make a change in your code, the version control system automatically creates a new version of that file.

Why do We use a Version Control System?

OK, So what does that exactly mean? That means if you say you have 3 features to your code, you have feature one, you have feature two, you have feature Three.

So initially you added feature one to your code and your code works fine, right? Then you added feature two to your code, your code works fine. And then again you added feature three to your code and then the error occurs right? Your application stops working.

Now you have two options with you. Either you can manually remove feature three from your code and then see if your code starts working or not. Or you can just revert to feature two from your version control system and your code obviously will be working as fine as it was when you created feature 2.

OK, so for this very exact reason, we use a version control system right now. Let me explain it to you more by taking an example.

Understanding the Version Control System with an example

So say you are a person, you are a developer, right? And you open a company. You open a software company and you develop your first code, right? Develop your first software and you send it to your clients.

You say that you know this is the software and I’ve added some features to it. I just want to give you the demo and I’m going to add more features in the future as we go on, right?

So the client says, OK, so your software looks good. So please add the new features as soon as possible and we will need it by next month. So what do you do? You hire some more developers and you hand out your code to these developers.

So say the software that you wrote becomes version one, right? So you hand out the copy of that code to all the developers that you have hired and that copy is version one that they have to work on, right? Right.

So what developer B does is he finishes his share of codes to developer B. You give one set of features to developer C you give another feature, a set of features, the developer D you give another set of features.

So Developer B finishes work and his code becomes version 2 because he just made the changes to what is existing on the production server over here, right? So on the production server, we have version one.

So whatever code was here, he has added his code to it and he is now giving it to Developer A to check whether it’s working or not. And if everything goes fine then developer A will just replace the code which is there on the production server.

OK, now the problem occurs over here when developer C finishes his work. Now remember guys developer C was working on version one, he was not working on the latest version, right? The latest version also has features of Developer B, right?

So I mean basically by the end of this, you want all the features that is of Developer B, Developer C, and Developer D to be in the same code. But because they’re all developing them separately, you get different sets of files with their features on them, right?

So now if Developer C is giving his code file to you, this code file is not version three. The reason is that he does not have the changes of version 2. So let’s say his file is version 1.1. So he gives it to developer A. Now developer A checks whether his features are working or not and what he does once he verifies that version 1.1 is working fine, he adds the changes that were there in version 2 to this file and then he comes up with version three.

Now developer A checks whether his features are working or not and what he does once he verifies that version 1.1 is working fine, he adds the changes that were there in version 2 to this file and then he comes up with version three.

Right now this is a very tedious process guys. Imagine if you have more than 50 or 60 developers in your company and you have one architect who is making sure that he’s integrating all the changes properly after checking.

It becomes a hectic task and also this task is very error-prone. It could be that all the developers have made their features fine it ran fine on their system and they did it perfectly.

But while integrating the code, developer A made some you know, some errors and that’s why the code is not working. It’s more than possible, right? So this was manual and hence it was error prone right?

Similarly, when developer D finished work again he just worked on version one and added changes to version one and now his code is not exactly version 4 but it is version 1.2.

So verifies if version 1.2 has all the things and if it has all the things. If all the features are working fine, he adds all the features of version 3 to 1.2 and then updates it on the production server to version four.

OK, so this was the way you know people were working when version control systems were not there. Now obviously there are a lot of problems in the way of working over here.

Problems before the version control system

So guys, versioning is manual as we can see any versions that you have to maintain for your file, have to be a manual effort.

The second thing is team collaboration is very time-consuming. So these are just three people who are working. Imagine you’re working with 50 or 60 people.

As I said, it will take a lot of time for the person who is integrating the changes to come up with the new version to update it on the version to update it on the production server, right? So it was very time consuming, it was hectic and it was also very error prone. OK,

Third Point is there was no easy way to access previous versions, right? So if say developer B wanted to see what developer A did, there is no system in place or there is no central server where all the files are saved in one place and this developer could just go over there and download the files from over there right?

There is no version like that. Also, if you know there is some problem while the architect uploads your new version of code to your production server and says it doesn’t work out on the production server, there is no easy way to revert to the previous version.

It is a very manual way of basically taking away the version 4 code first, adding version three which is the older file over there, and then seeing if the software is working or not right?

So like I said, there’s no way to revert to changes, there’s only a manual process. Manually take away the files that are not working and put the files that are working over there right?

And the 4th point is multiple versions took up a lot of space. Now the awesome thing about version control systems is guys, that it only saves the changes. It does not change all the files again.

Let’s understand the problems with an example

For example, you have a one or two MB, you have a 2MB file of code and you give it to your developers for work. Right now the developers added their version of the code and the file becomes 4 MB, right?

So version one was two MB and now when you commit it to or you save it on your system, you’ll save it as a separate file under a folder called version 2. So in all now, your whole code base is 6 MB, 2MB for version one, and 4 MB for version 2.

But if I want to tell you that version control systems only you know save the changes and at the same time you will feel there are two versions of a file, that would be awesome, right?

In that case, all your repository is going to size up to is 4 MB, right? Version one will size up two MB and then version 2 Because the changes are two MB and the version control system only saves the changes, it’ll save just two MB in version two.

However, if you go inside the version 2 folder and click on the file, you’ll be able to see the whole file. But in the back end the way the version control system is saving the files, you know your whole repository file or your whole repository of the code base is just going to size under 4 MB right?

So that is an awesome thing that git or any other version control system does and therefore you know when you were doing it manually. When we were managing everything manually, a lot of our space was also getting wasted because we were not using any version control system.

Advantages of Version Control System

Now, because we have version control systems today, versioning has become automatic. So this problem is solved.

The second thing is team collaboration is very simple right? The integration of the core happens automatically and very quickly. So it is less error-prone and also it is less time-consuming right?

The Third thing is there is easy access to previous versions. So if you want to revert to a previous version, all you have to type in is the revert command for that particular version control system and revert to the previous version which is running perfectly on the server where you’re trying to revert to the code.

The fourth thing is that only modified code is stored across different versions, hence saving storage.

The Bottom Line

In the ever-evolving landscape of web development, a Version Control System stands as a cornerstone, shaping projects and fostering collaboration. From streamlining teamwork to ensuring code integrity, a VCS is the unsung hero of efficient coding practices. Embrace the power of version control, and elevate your web development endeavors to new heights.