Git - The Version Control System That Actually Won

What is Git and Why Does It Rule Everything

Git started as Linus Torvalds' middle finger to proprietary version control after BitKeeper revoked the Linux kernel team's free license in 2005.

Linus built Git in two weeks because he was pissed off and needed something that wouldn't suck for managing thousands of kernel developers.

The result changed software development forever. Git's distributed model means every developer has a complete copy of the project history.

No single point of failure, no waiting for a central server to respond, no wondering if your code survived the server crash.

Git's weird architecture choices actually make it blazingly fast. Everything is stored as content-addressed blobs using SHA-1 hashes (moving to SHA-256 in Git 3.0).

When you commit, Git doesn't store file differences

• it stores complete snapshots and uses clever compression to keep things efficient.

GitHub's 2018 acquisition for $7.5 billion proved Git's dominance.

Microsoft didn't just buy a code hosting service

• they bought the infrastructure that runs modern software development. Stack Overflow's 2025 survey shows 93.87% of developers use Git, making it more universal than JavaScript. JetBrains' 2024 survey confirms similar adoption rates across all programming languages.

The Git ecosystem is massive: GitHub hosts over 100 million repositories, GitLab serves enterprises, Bitbucket handles Atlassian integration, and SourceForge... exists.

Git powers everything from personal dotfiles to Microsoft's 300GB Windows repository with over 3 million files.

Git won because everything else either died (RIP SVN), costs a fortune (fucking Perforce), or has zero community (Mercurial).

It's not perfect

• beginners spend months learning to unstage files and veterans still accidentally force-push to main. But Git works, scales, and every tool worth using integrates with it.

The latest Git 2.51 release (August 18, 2025) continues preparing for Git 3.0 with SHA-256 support, performance improvements, and the new reftable backend becoming default. These aren't flashy features, but they'll handle the next decade of exponential repository growth.

Git's three-stage architecture confuses everyone initially. You have the working directory (your actual files), the staging area (what Git calls the \"index\"), and the repository (the committed history). Spent my first month asking "why do I have to git add files I already changed?" The staging area is pure sadism, but it enables surgical commits where you can stage specific hunks of changes.

Content-Addressed Storage

Everything in Git is identified by SHA-1 hashes (moving to SHA-256 in Git 3.0). Files become blobs, directories become trees, and commits are just objects pointing to other objects. This makes Git's storage incredibly efficient and enables features like automatic deduplication. If you have the same 1MB file in 100 commits, Git stores it once.

The hash-based system also makes Git cryptographically secure by design. You can't change history without changing hashes, which makes tampering detectable. CVE-2025-48384 affects Git on Linux/macOS when cloning malicious repositories with submodules, but the core design remains solid.

Distributed by Default

Unlike centralized systems like SVN, every Git clone is a complete repository. Your laptop has the same capabilities as GitHub's servers. This distributed model eliminates single points of failure and makes operations lightning fast since everything happens locally.

Git's branching model treats branches as lightweight pointers to commits, not heavyweight directory copies like SVN. Creating a branch is literally writing 40 bytes to a file. Switching branches updates your working directory to match the branch state, which is why Git yells at you about unmitted changes.

The Plumbing vs Porcelain Split

Git separates low-level \"plumbing\" commands (git cat-file, git write-tree) from high-level "porcelain" commands (git add, git commit). Most users never touch plumbing commands, but they're what power Git's internals. This layered architecture lets tools like GitHub Desktop build custom interfaces while leveraging Git's proven core.

Platform Gotchas That Will Ruin Your Day

Windows: Git Bash provides a Unix-like environment, but Windows' 260-character path limit breaks deep directory structures. Git LFS is mandatory for any binary files over 100MB. Line ending conversion (`core.autocrlf`) causes mysterious diff issues.

macOS: Case-insensitive filesystem by default means README.md and readme.md are the same file, breaking Linux-developed projects. Git's precomposed Unicode handling differs from HFS+, causing filename encoding issues.

Linux: Usually the smoothest experience since Git was born here. Watch out for filesystem permissions if you're sharing repositories between users or containers.

Performance at Scale

Git handles Microsoft's Windows repository: 300GB with over 3 million files. They use custom tooling like VFS for Git (now Scalar) to make this workable, but stock Git chokes on repositories this size.

For normal projects, Git's performance is excellent. Local operations (diff, log, branch) are instant since they don't hit the network. Remote operations (fetch, push) depend on your connection and the remote server's capacity.

The Git 2.51 release includes reftable backend improvements that dramatically speed up repositories with thousands of branches and tags. These optimizations matter when you're dealing with CI/CD systems that create feature branches automatically.