What is version control, and how does Git's distributed model differ from older centralized systems in a way that actually matters for DevOps workflows?

Version control is like Google Docs' version history, except built for code and for teams working on the same files simultaneously without stepping on each other. Every edit is recorded as a distinct, attributable change, so if someone breaks something, you can see exactly what changed, who changed it, and roll it back precisely — instead of the old approach of emailing zip files named final_v2_ACTUALLY_FINAL.js back and forth.

Git was designed by Linus Torvalds in 2005 specifically because the Linux kernel team's existing centralized version control system (BitKeeper) couldn't handle their scale and collaboration model. Centralized systems like Subversion keep one master copy of history on a server; every commit requires a network round-trip, and if that server is unreachable, nobody can commit at all. Git's distributed design means every clone is a complete, independent repository with full history, so committing, branching, and viewing history all happen instantly on your local machine with zero network dependency.

Internally, Git stores each commit as a snapshot (not a diff) of the entire project, linked to its parent commit, forming a directed graph. A branch is just a lightweight, movable pointer to a specific commit — creating one is nearly instant because it doesn't copy any files, it just writes a 41-byte reference. When you push, Git compares your local commit graph against the remote's and transfers only the commit objects the remote doesn't already have, which is why pushes are fast even on large repositories with deep history.

In a DevOps pipeline, this distributed model is what makes CI/CD practical: a CI runner can clone the full repository in seconds, and every commit pushed to a shared branch is what triggers the pipeline — the commit itself becomes the unit of automation, not a manually-uploaded artifact. Production incident response also depends on this: git bisect lets an engineer binary-search through hundreds of commits locally, without touching a central server, to find the exact commit that introduced a regression.

The gotcha: because every clone has full history, secrets accidentally committed (API keys, passwords) are effectively permanent and public the moment they're pushed, even if you delete them in a later commit — the old commit object with the secret still exists in everyone's local history and in the remote's history until it's explicitly purged from every clone. This is why secret-scanning in CI and pre-commit hooks matter so much more in Git than they did in older centralized systems.