In my previous article, I explained what GIT is. Now, let me ask you a simple question: Why were Version Control Systems created? We had storage solutions like pen drives and hard drives, and sharing files was easy. You could just copy and paste the files to share them with your friends or team members physically. So, what was the problem?
This is where I would like to introduce you to PenDrive Analogy.
The Pendrive Analogy
Let’s assume a situation where Alice is working on a codebase. Now while working on the project Alice realises that she might need to take a leave for 3 days due to some work, so she requests her team member Bob to develop a remaining feature for her.
Bob agrees and Alice copies the files from her computer in a pendrive and hands over the pen drive to the Bob and left the office. Bob plugs the pen drive in his computer, copies the code files and start working on the codebase.
While working on the remaining features Bob realises that certain existing part of the code also needs to be changed in order for this feature to work. So, he tweaks certain existing parts of the code as well including deleting a few existing code, but at the end of the day, he achieved the result. He had successfully coded the feature, tested it by running the code and calls it the day!
Three days later, Alice comes back to the office and found the pen drive in the Bob’s cubicle with the note “I’m going on a vacation and I have coded the remaining feature. Tested it and it worked perfectly”. Alice took the pen drive and after few daily office chores, she sits down to work on further tasks on the codebase.
She plugs the pen drive into her computer, copies the code files to her system and opened the code editor, executes the code and found the feature coded by the Bob is working perfectly fine. She was happy to see the feature working but then immediately notices an issue.
Few of the other features that she had worked on earlier are broken and some are not responding well. She switches back to the code editor and…
She Freezes.
Bob has added enormous amount of the code into developing that feature and also have modified the code for some of the previous features. Since, she has replaced the old version of codebase from her computer with Bob’s version, she is now stuck with no way out to know what changes Bob has made to the codebase and how code used to look earlier.
She panics! Asks another team member, if they had the old version of the codebase present on their system. Luckily, she did find it but now she had two versions Accounting_software_old.zip and Accounting_software_new.zip. Now the old one doesn’t have the feature that Bob developed and new one is broken and she needs to show this to the client in upcoming meetings.
She is now stuck playing a game of “Spot the Difference” manually, line by line, while the client meeting clock ticks down. She calls Bob, who is gone on vacation and tells her about the problem. Bob goes to his hotel room, took his laptop out and checks and found some issues, he immediately fixes it but now the problem arises, how to share it back to Alice?
Another issue is that now there exists another version of the codebase with the Bob’s version Accounting_software_new_fixed.zip, which is again an issue. Which codebase will now be considered as source of truth? Alice’s old one? Bob’s feature one? or the one Bob just fixed?
Somehow, Bob saves the day by sending the new code as Email!
Why the Pendrive System Failed
- The Nightmare of No History (No Undo Button): When Alice replaced her old files with Bob’s new ones, she effectively erased the past. If Bob made a mistake, there was no way to go back to how the code looked yesterday. The past was overwritten forever.
- The Nightmare of Blindness (No Change Tracking): Alice knew that the code was different, but she couldn’t see what was different. She was forced to play a manual game of “Spot the Difference” across thousands of lines of code.
- The Nightmare of Truth (Source of Truth Problem): By the end of the story, we had
Accounting_software_old.zip,Accounting_software_new.zip, and the emailedAccounting_software_new_fixed.zip. Which one is the real project? If Alice fixes a bug in the “Old” one while Bob adds a feature to the “New” one, they have created two separate realities that will be incredibly hard to combine.
This is why version control systems like GIT, SVN, Mercurial etc were created.
How Version Control Systems Solved this Problem
Version Control Systems (VCS) were created specifically to prevent the “Pendrive Panic” we just described.
- Tracking the Changes: Think of VCS like a CCTV camera for your code. It doesn’t just save the file; it tracks every single line that was added, deleted, or changed. You don’t just see that the file changed but also what exactky changed.
- Accountability: In our story, Alice didn’t know for sure what Bob touched. VCS tracks exactly who made the change.
- Ability to Migrate Back: This is the biggest lifesaver. Since VCS saves a snapshot of your project every time you commit, you have an infinite Undo button. If the new code crashes the app, you can instantly roll back to the version from yesterday that was working perfectly.
- Ability to Work on Multiple Features : This allows Alice and Bob to work in parallel universes. Alice can work on her feature in a separate “branch” without touching Bob’s code. They can both code simultaneously without overriding each other’s files.
- Collaboration: No more emailing Zip files. VCS acts as a central hub (like on a server) where everyone syncs their work. It becomes the single source of truth for the whole team.
Conclusion
We learned from the story that version control systems does simplify our lives a lot by tracking changes across entire projects and by providing ability to easily collaborate with others by hosting it on a server, hence solving the traditional pen drive problem.