Motivation

Back in school, some friends and I worked on a C++ project — a replica of a Pizza Reservation system — in a single file, main.cpp. As we kept adding features and fixing bugs, we ended up saving it as "main_final_latest_version.cpp." On submission day, merging everything back together, we lost track of the changes — and we had no backup at all.

The simplest solution to that kind of problem: version control.

What is Version Control?

In software engineering, version control (also called revision control or source control) is a class of systems that manages changes to programs, documents, or other collections of information.

In plain terms: imagine you failed an exam and wished you had a time machine to go back and prepare only for the questions that actually showed up. That's what a Version Control System (VCS) gives you — the ability to travel back through a file's history.

Features of a VCS

• Backup and restore — jump back to any saved point in time.
• Synchronization — share files and stay up to date with others.
• Short-term undo — throw away a mess and return to the last known good version.
• Long-term undo — jump back to a version from a year ago to see what changed.
• Track changes — leave messages explaining why a change happened.
• Track ownership — every change is tagged with who made it.
• Sandboxing — make and test changes in isolation before committing them.
• Branching and merging — work on a separate copy, then merge it back in.

Vocabulary worth knowing

Basic:

• Add — start tracking a file.
• Revision — a version number (v1, v2, ...).
• Head — the latest revision in the repo.
• Check out / check in — download / upload a file's changes.
• Changelog — history of changes to a file.
• Update/sync — pull the latest revisions.
• Revert — discard local changes, reload the latest version.

Advanced:

• Branch — a separate copy for isolated work.
• Diff — the difference between two files/revisions.
• Merge — apply changes from one branch into another.
• Conflict / resolve — contradictory changes, and fixing them.
• Locking — preventing others from editing a file until you're done.

Centralized vs. Distributed

In centralized version control (e.g. Subversion), everyone has a working copy, but there's one central repository — as soon as you commit, others can update and see your changes.

In distributed version control (e.g. Git, Mercurial), everyone has their own full repository and working copy. For others to see your changes, four things need to happen: you commit, you push, they pull, and they update. Distributed won — that's what most teams use today.