Version Control System (VCS): What It Is and How It Works - Quiz

A version control system (VCS) is a tool that records the history of changes to project files — who changed what and when — and lets you return to any earlier state at any time. In practice a VCS solves six problems: it keeps a change history, where every commit carries an author, a timestamp and a message; it allows rollback of a single file or of the whole project to an earlier state; it enables team collaboration, merging the edits of several developers and reporting a conflict where they overlap instead of silently losing code; it supports branching, so experiments and new features never break the working version; it acts as a backup of the project together with its entire history; and it is the foundation for CI/CD, where builds, tests and deployments are triggered by repository events. A repository is not only for source code: teams also version configuration files, SQL migrations, build scripts, documentation and infrastructure as code.

A CVCS keeps the complete project history in a single central repository on a server, while each developer holds only a working copy of the files. As a result almost every operation — viewing the log, creating a branch, committing — requires the network, the server becomes a single point of failure, and branching and merging are expensive. In a DVCS every developer gets a full copy of the repository together with the whole history: commits, log browsing, creating and merging branches happen locally and almost instantly, and the network is needed only to exchange changes (push and pull). A full history on every machine gives resilience, and cheap branching is what makes feature branches and pull requests practical. Examples of CVCS: Subversion (SVN), Perforce (Helix Core), Microsoft TFS/TFVC, ClearCase. Examples of DVCS: Git, Mercurial, Bazaar, Fossil. Git is the industry standard today, but centralized systems are not dead: Perforce owns game development because of multi-gigabyte assets and file locking, and SVN is alive in legacy banking and telecom systems.

The cycle is the same for any VCS and has six steps: get the code, create a branch for the task, make the changes, record them in a commit, sync with other changes, and publish the result for review. In Git a minimum set of commands covers it: git clone https://github.com/user/project.git — download the repository with its history; git checkout -b feature/login — create a branch for the task and switch to it; git status — see what changed and what is staged; git add . — stage the changes; git commit -m "Add login validation" — record them locally; git pull --rebase origin main — bring in commits made by others; git push origin feature/login — publish the branch; git log --oneline --graph — inspect the history. Keep in mind that a commit in Git is a local operation: until you run push, nobody else sees your work and it is not a backup. This is the key difference from SVN, where commit goes straight to the server.

There are six typical mistakes. First, one huge 3,000-line commit per week: such history is unreadable and impossible to roll back partially, while a commit should be one finished logical change. Second, messages like "fix", "wip" or "123": they are useless a month later, so state what changed and why, for example Fix NPE in UserService when email is null. Third, no .gitignore, which lets target/, *.class and .idea/ end up in the repository as noise, conflicts and extra megabytes. Fourth, passwords and keys in a commit: deleting the file in the next commit is not enough, the secret stays in history and must be treated as compromised. Fifth, working only in main, where an unfinished feature blocks the release for the whole team. Sixth, a careless git push --force to a shared branch: it rewrites history and wipes commits made by other people — precisely the disaster version control was supposed to prevent.