Version control is a system that records changes to a file or a set of files over time so that specific earlier versions can be recalled later. The Pro Git book, written by the maintainers of Git, defines it in exactly those terms and lists what it makes possible: reverting files or whole projects to an earlier state, comparing changes over time, seeing who last changed something, and recovering from mistakes.
The need for version control showed up as soon as software projects grew beyond one person. Marc Rochkind’s 1975 paper on SCCS describes the situation it was built to fix: on a large project with many programmers and many modules, copies of source files multiplied, and it became hard to know which version was current or how a file had reached its present state. Keeping a single tracked history per file solved that.
Pro Git groups version-control systems into three broad styles. Local systems keep a simple database of changes on one machine; RCS was a popular example. Centralized systems, such as CVS, Subversion, and Perforce, keep the project on a single shared server that everyone checks files out from. Distributed systems, such as Git and Mercurial, give every contributor a full copy of the project and its complete history.
Underneath all of these is the same core idea: instead of saving loose, dated copies of files by hand, you let a tool keep the history for you. That history is what makes safe experimentation, parallel work by many people, and clear answers to “who changed this and why” possible. Version control is now treated as a foundation of modern software development.