Discovering the Need for Version Control Systems

There are many version control systems in the market, but the most popular version control system is Git. But have you ever asked this question to yourself: why does this even exist? What were we developers doing when there was no Git? Let’s try to uncover this.

The Pendrive Analogy

Let’s start with a scenario. You got a freelance project where you need to develop software for a manufacturing company to manage inventory. You asked all the requirements and decided to take up this project and deliver the final software.

Initially, you started planning the flow of the project and began writing code for each feature one by one. Eventually, the code will definitely grow. Let’s say you got stuck on one feature and decided to ask for help from your friend. What will you do? You copy the project folder and paste it into a pendrive and give that pendrive to your friend.

Until now, it is fine. Your friend wrote that feature and also noticed some bugs in previous features, so he fixed those features as well. He told you about everything he did and added a new project folder called “project_v1”.

Now you take that pendrive. As you have not been coding for some time, it is somewhat difficult to understand the code. You need to go through the whole codebase and understand what he changed, but it will be difficult to understand exactly what the other person changed. So, as you have the previous “project” folder, you can open that and compare that code with the code in “project_v1”. But honestly, it is a mundane and time-consuming task. Anyway, you live with it because at the end of the day you want your project to be completed without any bugs.

Problems That We Are Facing

As you can understand, we are not able to track the code.

“When was this code written?”

“Did I write this or did my friend write this?”

The source of truth is the pendrive. Whoever has this pendrive has the updated code. Let’s say your friend notices some bugs in his feature, so he fixes them on his machine. But it will not automatically update in your pendrive. Either your friend needs to send the updated code via email or take the pendrive and copy-paste the updated code again.

Also, imagine this scenario: you also noticed some bugs in his feature and you changed that exact file and code in your own way. Now you both changed the exact same file and code, so extra effort and time are spent here, and you two are out of sync.

If you maintain previous code in different folders, it will consume pendrive space unnecessarily. If you delete those folders, you can’t even manually compare the code to know what was changed and what was not.

Whoever has the pendrive assumes that they have the updated code, and also only one developer can work on that project at a time. So basically, collaboration doesn’t exist.

If the other person changed something significant in the code, then we end up with different versions of the code, half of the features are in one place and the other half in another place. The code becomes a complete mess.

And this mess is just between two people. What if some other people want to contribute? It will be a bigger mess. At the end of the day, you feel frustrated, the code will be buggy, and you just want to start the project from scratch again.

System That Can Solve These Problems

Let’s say we created a software called Code Tracker (CT). This software’s job is to track the changes happening in the code. We can install this software on the pendrive, and whoever changes the code, it tracks their name, time, and which part was there before the change and after the change (diff of the code).

This solves the code tracking problem, but still we have one more problem: collaboration. Whoever has the pendrive can change the code. Only one developer can work on that code at a time.

To overcome this collaboration problem, we need to get rid of the pendrive.

Now, instead of a pendrive, we can put a server. Let’s call it “Code Tracker Server”. We can access this through the internet without going out of our home.

But does just pushing our code and pulling the updated code solve the problem? No. We can get the updated code, but we don’t have any clue about who changed which part of the code or what code they actually contributed.

So we install “Code Tracker” software onto this server. Basically, this server is hosting the “Code Tracker” software. Now we can track the code, and this “Code Tracker Server” acts as a single source of truth for the updated code. This actually solves the collaboration problem and the code tracking problem.

This Code Tracker software === Git.

Code Tracker Server === GitHub.

Git → version control system (runs locally)

GitHub → remote hosting platform for Git repositories

Even though we have many other VCS (Version Control Systems) and VCS remotes, both Git and GitHub are widely used and popular among developers.

Summary

In summary, Git exists because managing code by copying folders, using pendrive, and sending files manually does not scale and quickly becomes chaotic. Without a system, developers cannot track changes, identify who wrote what, or work together at the same time. Git solves these problems by recording every change, maintaining history, and providing a single source of truth. When combined with a remote like GitHub, it also enables real collaboration. This is why version control systems are not optional but essential in modern software development.