Lesson 2 of 51 ~15 min
Course progress
0%

Why Git and How It Thinks Differently Than Other VCS

Discover how Git revolutionized version control by enabling distributed, peer-to-peer collaboration and making branching and experimentation effortless.

Version control is like oxygen for modern development. You don’t notice it when it’s flowing, but you suffocate when it’s missing. Long before Git, teams lived with systems like CVS, Subversion, or Perforce. These tools kept track of history, but they always felt like clerks stamping papers—slow, bureaucratic, and slightly resentful when you asked them for something complicated. Git changed the conversation entirely. Instead of a centralized office with a single ledger, Git handed every developer the entire library. You’re no longer a visitor at the archive; you’re a librarian carrying the whole collection in your backpack.

This shift in thinking is subtle but profound. Traditional VCS saw history as a series of events controlled by a single master authority. Git views history as a graph, a flexible structure that can be shaped, rewritten, forked, and merged back again. Where older systems punished experimentation by making branches expensive, Git thrives on branching. Its very architecture encourages you to experiment, to diverge boldly, and to recombine later without fear. In other words: Git democratized history itself.

The Problem Git Solved

Back in the early 2000s, open source projects like the Linux kernel were bursting at the seams. Thousands of contributors across the globe were hacking on the same codebase. Centralized VCS could not handle the sheer volume of patches. Subversion groaned. BitKeeper, a commercial tool, temporarily filled the gap, but licensing disputes made it unsustainable. Linus Torvalds, being Linus Torvalds, decided to write his own system in a matter of days. The result: Git.

The genius of Git is that it didn’t merely replace BitKeeper; it redefined how distributed collaboration could work. Every clone is complete. Every developer is sovereign. The network is peer-to-peer, not hub-and-spoke. This is why Git isn’t just a tool; it’s a philosophy. You stop thinking in terms of “checking in to the central database” and start thinking in terms of snapshots, branches, and merges as personal creative acts.

A New Mental Model: Snapshots, Not Diffs

Subversion and CVS treat history like a ledger of changes. Each commit is a diff, a delta, an incremental patch applied on top of the last. Git treats history differently. Each commit is a full snapshot of your project at that moment. Of course, Git stores snapshots efficiently (using clever object storage and compression), but conceptually you’re not applying deltas—you’re freezing time. That means you can teleport anywhere in history instantly.

Here’s a tiny visualization:

gitGraph
  commit id: "Initial"
  commit id: "Added feature"
  commit id: "Fixed bug"

Each commit is a snapshot, not just a change. This mindset is crucial. When you check out a commit, you’re not replaying diffs—you’re inhabiting an entire universe frozen in amber.

Branching as Cheap Parallel Universes

In centralized VCS, branching was costly. Creating a branch meant duplicating large amounts of data on the server. Merging often caused nightmares. In Git, a branch is just a movable pointer to a commit. That’s it. Branching is so cheap you can do it for every tiny experiment. This leads to a culture of experimentation: want to try a new refactor? Branch. Want to play with an alternative algorithm? Branch. Want to explore a bad idea? Branch, and throw it away guilt-free.

Visual comparison of old vs Git:

flowchart LR
  A[Centralized VCS Branch] --> B[Heavy, slow, server dependent]
  C[Git Branch] --> D[Lightweight pointer, local, instant]

Concrete Example: Trying an Experiment

Let’s say you’re building a web app. In Subversion days, you’d be terrified to branch, fearing painful merges. With Git:

git checkout -b experiment/new-layout
# Hack, commit, test
git checkout main
git branch -D experiment/new-layout   # delete when you’re done

You just created and destroyed a universe in seconds. This is not a small feature—it is the heart of Git’s philosophy: empower experimentation.

Collaboration Without Permission

Another way Git thinks differently: you don’t need permission to have a complete history. With Git, every clone is equal. You can fork, branch, rewrite, merge. Collaboration doesn’t require a central gatekeeper. Platforms like GitHub and GitLab add social layers (pull requests, reviews), but Git itself doesn’t care. That’s why open source exploded after Git—it allowed thousands of developers to collaborate asynchronously, across continents, without begging a server for approval.

Visualization: Decentralized vs Centralized

flowchart TD
  subgraph Centralized
  S1[Client] -->|Commit| Server
  S2[Client] -->|Commit| Server
  end

  subgraph Git Distributed
  D1[Dev A Repo]
  D2[Dev B Repo]
  D3[Dev C Repo]
  D1 <-->|push/pull| D2
  D2 <-->|push/pull| D3
  D1 <-->|push/pull| D3
  end

This illustrates the radical difference: no single server owns the truth. History is shared, but sovereignty is local.

Think Different Mindset: Owning Your History

Git teaches you to think like a historian. Your repo isn’t just code; it’s a story. Every commit is a paragraph, every branch a subplot, every merge a reconciliation. You’re not just coding—you’re authoring history. Once you internalize this, you stop fearing Git. Instead, you embrace it as a narrative tool. The DAG (directed acyclic graph) becomes your storyboard.

Solo Workflow Example

You’re a solo indie developer writing a Python tool. Git gives you safety nets:

git init
git add .
git commit -m "Initial commit"
git checkout -b feature/cool-idea
# hack hack hack
git commit -am "feat: prototype new idea"
git checkout main
git merge feature/cool-idea

Result: you explored safely, merged when ready, history recorded cleanly. If it failed, you could simply delete the branch.

Team Workflow Example

Now imagine a team of three. Each creates branches, pushes to a shared remote, opens pull requests. Git’s branching model encourages parallelism. Instead of queuing changes through a bottleneck, everyone works concurrently. Merges happen often, conflicts are resolved incrementally, and velocity increases.

Mermaid Graph of Team Work

gitGraph
  commit id: "main start"
  branch featureA
  checkout featureA
  commit id: "feature A work"
  checkout main
  branch featureB
  checkout featureB
  commit id: "feature B work"
  checkout main
  merge featureA
  merge featureB

The DAG shows how independent lines of work converge back. This isn’t chaos—it’s collaboration as jazz.

Philosophical Takeaway

Git doesn’t just store files. It changes how you think about code, about collaboration, about mistakes. Mistakes aren’t fatal; they’re recoverable. Experiments aren’t expensive; they’re expected. Collaboration isn’t hierarchical; it’s peer-to-peer. This mindset liberates developers. You no longer fear history—you shape it.

By now you should see that Git is not just “another VCS.” It is a fundamentally different way of conceptualizing history, collaboration, and experimentation. Where others punish branching, Git celebrates it. Where others centralize power, Git distributes it. Where others treat history as fragile, Git treats it as clay. This crash course will not only teach you commands; it will teach you to think different. Because once you change how you think about history, you change how you build the future.