A version control system (often abbreviated VCS) is software that records changes to a set of files over time, so that you can recall specific versions later, compare how files differed at any two points, see who made each change and why, and restore earlier states if something breaks. At its heart, a VCS does three things: it tracks every change made to a file, it stores a complete history of those changes rather than overwriting old data, and it coordinates multiple people editing the same files so their changes can be combined instead of colliding.

Without a VCS, teams historically resorted to painful manual workarounds: emailing zip files back and forth, naming folders “project_v2_final_reallyfinal,” or locking a file so only one person could edit it at a time while everyone else waited. Every one of these approaches breaks down as soon as more than a couple of people are involved, which is exactly why version control became one of the foundational tools of modern software engineering — used not just by programmers, but increasingly by writers, designers, and data scientists managing any evolving set of files.

In the earliest days of software development, source code often lived as a single copy on a shared computer, and developers coordinated changes by talking to each other directly — “I’m working on the login module today, don’t touch it.” This worked only because teams were tiny. As software projects grew from a handful of files to thousands, and teams grew from a few engineers to hundreds working across different time zones, informal coordination became impossible. Two of the most damaging failure modes were lost work (someone’s changes silently overwritten by someone else saving over them) and untraceable bugs (a defect appears in production and nobody can determine which change introduced it, because there’s no historical record to search through).

flowchart TD
    A["Working Copy
(files on disk)"] -->|record a snapshot| B["Commit / Revision"]
    B --> C["Repository
(full history of commits)"]
    C -->|create| D["Branch A
(experiment)"]
    C -->|create| E["Branch B
(main line)"]
    D -->|merge back| F["Merged History"]
    E --> F
    

What an interviewer may ask: “What’s the difference between a working copy and a repository?” The working copy is the live, editable state of your files on disk right now; the repository is the permanent, historical record of every past state those files have ever been in.

When you make a change and record it (a “commit” in most modern systems), the VCS needs an efficient way to store that new state without simply duplicating the entire project every single time — that would consume enormous amounts of storage on any project with a long history. Two broad strategies exist across the history of version control tools. The older approach, used by systems like SVN and CVS, stores each revision as a delta — essentially “here’s what changed since the last version” — reconstructing any full version by replaying deltas in sequence. The newer approach, popularized by Git, stores each commit as a full snapshot of the entire project at that moment, but uses compression and content deduplication so that unchanged files aren’t stored twice, making snapshots nearly as space-efficient as deltas while being dramatically faster to reconstruct, since there’s no chain of deltas to replay.

The move from centralized to distributed systems is the single biggest architectural shift in version control history. In a centralized system, if the central server goes down, nobody can commit, view history, or compare versions — everything depends on that one machine. In a distributed system, every developer’s local copy is a fully functional repository with its own complete history, meaning work can continue offline and no single point of failure can take down the whole team’s ability to operate.

Version control systems sit at the center of a software supply chain, which makes their security meaningful beyond just “not losing work.” Integrity is a core concern: can anyone tamper with history and make it look like a different author wrote a change, or that a past version said something it never actually said? Modern distributed systems address this through cryptographic hashing, where each revision’s identity is mathematically derived from its content and its history, making silent tampering detectable. Access control matters too — centralized systems typically restrict who can commit directly to the shared history, while distributed systems separate “who can commit locally” (essentially anyone, since it’s their own machine) from “whose commits get accepted into the official shared history” (controlled by whoever maintains the central copy).