Module 1 Lesson 2: Git vs other version control systems

Not all version control systems are created equal. Before Git, the world was dominated by Centralized Version Control Systems (CVCS) like SVN (Subversion) and Perforce.

Understanding the difference between the "Old Way" and the "Modern Way" is crucial to understanding why Git works the way it does.

---

1. Centralized Version Control (The Old Way)

In a CVCS, there is a single central server that contains all the versioned files. Developers "check out" a few files from that central place.

The Problem:

• Single Point of Failure: If the server goes down for an hour, no one can collaborate or save versioned changes. If the server's hard drive is corrupted and backups haven't been kept, you lose everything.
• Offline Limitation: You must be connected to the network to do almost anything besides editing files. You can't commit, view history, or branch while on a plane or in a cafe with bad Wi-Fi.

graph TD
    Server["Central Repository Server"]
    Dev1["Developer A (Local Files)"]
    Dev2["Developer B (Local Files)"]
    Dev3["Developer C (Local Files)"]

    Server -- "Checkout/Commit" --> Dev1
    Server -- "Checkout/Commit" --> Dev2
    Server -- "Checkout/Commit" --> Dev3

---

2. Distributed Version Control (The Modern Way)

In a Distributed Version Control System (DVCS) like Git or Mercurial, clients don’t just check out the latest snapshot of the files; they fully mirror the repository.

The Advantage:

• Redundancy: Every developer’s machine is a backup. If the main server crashes, any of the client repositories can be copied back up to the server to restore it.
• Offline Speed: Since you have the entire history on your own disk, viewing the project's history or comparing versions is instantaneous. You don't need a network connection to commit your work.
• Advanced Branching: Git makes branching and merging so easy and fast that it changes the way developers work, encouraging them to create a new branch for every tiny feature.

graph LR
    subgraph "Server Repository"
        S_History["Full History"]
    end
    subgraph "Dev A Repository"
        A_History["Full History (Mirror)"]
    end
    subgraph "Dev B Repository"
        B_History["Full History (Mirror)"]
    end

    S_History <--> A_History
    S_History <--> B_History
    A_History <--> B_History

---

3. Why Git "Won"

While systems like SVN are still used in some legacy industries, Git is the industry standard for several reasons:

1. GitHub/GitLab/Bitbucket: The rise of these platforms made collaboration social and accessible.
2. Performance: Git's internal data structure (Directed Acyclic Graphs) makes it orders of magnitude faster at branching and merging than SVN.
3. The Linux Legacy: Being built for the Linux kernel gave it immediate credibility and "battle-tested" status.

---

Lesson Exercise

Goal: Identifying the System.

1. Research a popular open-source project (like React, VS Code, or the Linux Kernel).
2. Look at their "Contribute" page. What version control system do they use?
3. Try to find a project that doesn't use Git. (Tip: Look at very old Apache projects or game development engines like Unreal, which sometimes use Perforce).

Observation: You'll quickly see that unless there is a very specific reason (like handling 100GB binary files), the world has moved entirely to Git.

---

Summary

In this lesson, we established:

• CVCS (Subversion) relies on a central server, making it fragile and slow for remote work.
• DVCS (Git) mirrors the entire history on every machine, making it fast, redundant, and offline-capable.
• Git has become the universal standard for modern software engineering.

Next Lesson: We’ll dive into the specific "rooms" within your project where Git does its work: the Working Directory, Staging Area, and Repository.