Chapter 1: The Origin of Git & Why We Needed It

To understand Git, we have to travel back to a time when sharing code was a logistical nightmare. In this chapter, we will explore the historical problems of collaboration, the failures of early version control tools, and why Git’s distributed design was a revolutionary breakthrough.

---

🏢 The Real-World Analogy: Writing a Novel Together

Imagine you and three other authors are writing a 500-page fantasy novel together.

Scenario A: No System (The USB / Email Era)

You write Chapter 1 on your computer. You email the file novel.docx to Author B. Meanwhile, Author C also wants to edit Chapter 1.

1. Author B changes the hero’s name to “Arthur” and saves it as novel_v2.docx.
2. Author C changes the hero’s name to “Lancelot” and saves it as novel_final.docx.
3. They both send their files back to you.

Now you have two different files. If you copy Author B’s version, you completely erase Author C’s chapters. If you copy Author C’s version, you lose Author B’s work.

To merge them, you have to open both documents side-by-side and manually check every line of text. This is Folder Versioning, and it is exactly how programmers worked in the 1970s and 80s.

Scenario B: The Shared Folder (Centralized SVN Era)

To solve this, you put the novel.docx on a shared network drive (a central server).

• If Author B wants to work on the file, the server locks the file. Author C gets an error message: “File is locked by Author B. Read-only.”
• Author C has to wait until Author B finish editing and goes offline.
• If the shared drive breaks or the network goes down, nobody can write anything.

---

⚠️ The Failure of Centralized Version Control (CVCS)

In the 1990s, programmers built Centralized Version Control Systems (CVCS) like Subversion (SVN) and CVS. They moved away from locking files, allowing multiple people to edit. However, they kept the Central Server architecture.

Developer A (Working Copy) ──┐
Developer B (Working Copy) ──┼──► [ Central SVN Server ] (Holds all history)
Developer C (Working Copy) ──┘

The Three Critical Flaws of CVCS:

1. The Single Point of Failure: All history (who made changes, previous versions, deleted files) lived only on the central server. If that server’s hard drive crashed without a backup, the entire project’s history was wiped out. Developers only had the single version they were currently editing.
2. Network Dependency: To look at a file’s history, see who wrote a line, create a branch, or save a version, your computer had to make a network request to the central server. If you were on a train, plane, or had poor internet, you couldn’t use version control.
3. Slow Operations: Because every action required talking to a remote database over the internet, operations were sluggish. Creating a branch meant copying folders on a remote server, which could take minutes.

---

⚡ The Birth of Git: 2005

In 2005, the development team of the Linux Kernel (the core of the Linux operating system, comprising millions of lines of code written by thousands of global developers) lost their free access to a proprietary version control tool called BitKeeper.

Linus Torvalds, the creator of Linux, decided to write his own version control system. He locked himself in a room for about two weeks and emerged with the first version of Git.

Linus designed Git with three core principles:

1. Speed

Because the Linux kernel was so massive, commands had to run in milliseconds. Linus made sure Git did almost all calculations locally on the developer’s computer, rather than over a network.

2. Distributed Architecture

In Git, there is no master server database. When you run git clone, you don’t just download a snapshot of the files; you download a complete copy of the entire history database of the project.

  [ Local Machine A ]              [ Local Machine B ]
┌─────────────────────────┐      ┌─────────────────────────┐
│ Files + Full History DB │      │ Files + Full History DB │
└───────────▲─────────────┘      └───────────▲─────────────┘
            │                                │
            └──────► [ GitHub Remote ] ◄─────┘
                     (Backup/Sync Hub)

Every developer’s computer is a self-contained repository and backup. If the central hub (like GitHub) is destroyed, you can point your local repository to a new server, push your code, and the entire project history is restored instantly.

3. Cryptographic Integrity (SHA-1)

Git was built to be secure against accidental or malicious changes. Every file, directory, commit, and history step in Git is encrypted and labeled with a 40-character hexadecimal string called a cryptographic hash (using the SHA-1 algorithm).

For example: 2a8f9d0c1b3e7f4a5c6d7e8f9a0b1c2d3e4f5a6b

• If a single comma, space, or character in your code changes, the hash code changes completely.
• This makes it impossible to secretly change a file or history from two years ago; Git will notice that the hash doesn’t match and warn you of corruption.

---

💡 Summary of Chapter 1

• Before Git, we had folder duplication or centralized servers (SVN).
• Centralized systems were risky because if the central server went down, history was lost, and you couldn’t work offline.
• Git solved this by being Distributed: every computer holds a full backup database of the project history, meaning operations are incredibly fast and can run completely offline.

In the next chapter, we will look inside your computer to see where your files live when you run Git commands.

---

👉 Go to Chapter 2: The Three States & Architecture