Learn Git - History, Background & Why You Need a VCS

#Introduction

In episode 0 we prepared the environment: terminal, Git 2.4x, GitHub account, and SSH authentication. Now it is time to answer the most fundamental question: why do we need Git at all?

Before understanding how Git works, we must understand the problem it solves. Version Control System (VCS) was born from very real pain: lost work, team code overwriting each other, and the inability to answer simple questions like "who changed this line and why?". This episode guides you through the journey from chaos to the system we use today.

#The Problem of Code Management Without a VCS

#The Failure of Manual Versioning

Imagine this pattern — one that is very familiar at the start of every developer's career:

ls ~/projects
project_v1.zip
project_v1_fixed.zip
project_v2.zip
project_final.zip
project_final_beneran.zip
project_final_beneran2_FINAL.zip

See the problem: ambiguous filenames, no record of changes, and no one knows what is inside project_final_beneran2_FINAL.zip or when it was created. Undocumented versions mean unreliable versions. After a few months, archives like this are just digital junk.

#The Difficulty of Collaboration

Without a VCS, two developers editing the same file will overwrite each other's work. The only way to avoid it is fragile manual coordination ("you edit first, I will continue later"). There is no trace of who changed what, bugs slip in without anyone knowing when, and this manual approach always fails once the team grows.

#The Evolution of Version Control Systems

#Centralized VCS

The first generation of VCS — Subversion (SVN), Perforce — centralized the entire history on a single server. Developers check out to their local machine, work, then commit back to the server.

Its strengths: a single source of truth and centralized access control. But its weaknesses are fatal:

• Single point of failure — if the server dies, the entire project history is gone.
• Network dependent — every operation needs a connection; going offline means stopping work.
• Hard branching — creating branches on the server is expensive and conflict-prone.

#Distributed VCS

Git and Mercurial flipped this paradigm: every developer has a full copy of the repository — the entire history, every branch, all the data — on their local machine.

git clone https://github.com/akun/proyek.git

Note: git clone is not "downloading the latest files", but copying the entire repository database. The consequences are significant — consider the advantages below.

#Advantages of Distributed VCS

• Work offline — commit, log, diff, and branch are all local; a connection is only needed for push and pull.
• Fast — nearly every operation runs on the local machine without network latency.
• Full local history — the entire history exists on every machine; the server is not the only storage.
• Resilient — if the main server is lost, any local copy can replace it.

This is a philosophical shift: from "the server is the source of truth" to "every developer has a source of truth, and they synchronize with each other".

#A Brief History of Git: Born from Crisis

In 2005, the Linux kernel developers faced a problem: they used BitKeeper, a proprietary DVCS that revoked its free license. Linus Torvalds refused to go back to a centralized VCS that would hinder collaboration among thousands of contributors. So, within a matter of weeks, he built Git.

The criteria he set from the start:

• Speed — kernel patches number in the thousands per day; Git had to be as fast as possible.
• Simple design — a minimal data model, easy to understand and maintain.
• Full support for non-linear branching — thousands of contributors working in parallel.
• Data integrity — every object is identified by a cryptographic hash so data cannot change silently without being detected.

git log --oneline
a1b2c3d feat: tambah modul autentikasi
e4f5g6h fix: perbaiki null pointer di login
a7b8c9d Initial commit

Here you can see Git's power: every change is recorded neatly, with a unique hash and a message explaining its purpose. We will go deeper into the details in episode 4.

#Git's Core Philosophy

These four philosophies are not just slogans — you will encounter all of them directly in the upcoming episodes.

#Speed

Nearly all Git operations run locally without network communication. git log, git diff, and git branch feel instant even on huge repositories.

#Simple Design

Git does not store "changes" like most other VCSs, but rather snapshots of the state of all files at each commit. This simple data model is exactly what makes operations like merge and diff reliable.

#Non-Linear Branching

Branches in Git are extremely cheap — just a lightweight pointer. Workflows like "develop a feature on a separate branch, then merge it" become daily practice, not a dreaded exception.

#Integrity Through Cryptographic Hashing

Every Git object is hashed with SHA-1 (and now beginning to move to SHA-256). Changing a single bit in any file changes its hash and is immediately detected by Git.

#Closing

Here is the core of episode 1:

• Without a VCS, manual versioning and collaboration are disaster-prone.
• Centralized VCS (SVN, Perforce) has a single point of failure and depends on the network.
• Distributed VCS (Git, Mercurial) gives every developer a full local repository.
• Git was born in 2005 from the Linux kernel's needs, built by Linus Torvalds.
• Its philosophy: speed, simple design, non-linear branching, and data integrity.

In episode 2 we dissect the most fascinating part: Git's internal architecture — the three areas (working directory, staging area, repository), the snapshot model, and objects like blob, tree, and commit. There you will see why Git's design is so elegant. See you there!