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

You have probably seen a folder like this: report_final, next to it report_final_v2, and one line below — report_final_FINAL. Then a teammate emails you a zip with their edits, you unpack it over your folder, and last night's work is simply gone. Nothing to restore: there is no history, and no way to tell who changed what. Version control systems were invented to end exactly this kind of day.

A version control system (VCS) is a tool that records the history of changes to your project files — who changed what and when — and lets you return to any earlier state at any time. In short, a VCS is a time machine for your code plus a safe way for several developers to work on the same files at once.

What a version control system does

On any IT project several developers work on the same codebase, and the same questions come up immediately: who made this change and when, how do we undo a bad edit, how do we keep more than one version of a file, and how do we avoid overwriting each other's work. A version control system answers all of them.

What a VCS gives you in practice:

• Change history. Every saved snapshot (a commit) carries an author, a timestamp and a message, so you can see why a line was changed.
• Rollback. You can restore a single file or the whole project to the state it was in last week.
• Team collaboration. When two people edit one file, the VCS merges the changes — and where they overlap it reports a conflict instead of silently losing code.
• Branching. Experiments and new features live in separate branches and never break the working version.
• Backup. A repository on a server is also a copy of the project together with its entire history.
• Foundation for CI/CD. Builds, tests and deployments are triggered by events in the repository.

Types of VCS: centralized (CVCS) and distributed (DVCS)

Networked version control systems come in two flavours:

• CVCS (Centralized Version Control System) — centralized;
• DVCS (Distributed Version Control System) — distributed.

Centralized VCS (CVCS)

A CVCS keeps the complete project history in a single central repository on a server. Each developer has only a working copy of the files on their machine, usually of one revision, and every operation that touches history — viewing the log, creating a branch, committing — goes through the server. Centralized systems dominated commercial development through the 1990s and 2000s, before Git took over in the 2010s.

Advantages:

• a simple mental model: one shared line of history, fewer concepts for a newcomer;
• centralized access control — you can hide individual folders from part of the team;
• handles large binary files well (artwork, audio, game assets) and supports file locking.

Disadvantages:

• almost nothing works without a network connection, including commits and history browsing;
• the server is a single point of failure — if it goes down, the whole team stops;
• branching and merging are expensive and painful, so teams use them rarely.

Examples: Subversion (SVN), Perforce (Helix Core), Microsoft TFS/TFVC, ClearCase.

Distributed VCS (DVCS)

In a DVCS every developer gets a full copy of the repository together with the whole history. Committing, reading the log, creating and merging branches all happen locally; the network is needed only to exchange changes with other repositories (push and pull). Repositories can sync directly with each other or through a shared server — that is exactly the role GitHub or GitLab plays.

Advantages:

• offline work: history and commits are available with no connection at all;
• speed — most operations are local and never touch the server;
• cheap branching and comfortable merging, which is what makes feature branches and pull requests practical;
• resilience: the full history exists on every machine.

Examples: Git, Mercurial, Bazaar, Fossil.

CVCS vs DVCS: side-by-side comparison

The verdict for a typical Java project today is straightforward: use Git. But centralized systems are not dead. Perforce still owns game development because of multi-gigabyte assets and file locking, and SVN is alive in legacy banking and telecom systems. For an interview it is enough to explain the difference between the two models confidently and name two examples of each.

How version control works: the basic workflow

Whichever type of system you use, the day-to-day cycle looks the same:

1. Get the code. Clone the repository (clone) or update your local copy (pull; in SVN it is update).
2. Create a branch. One branch per task, so the main line of development stays untouched.
3. Make changes. Implement the feature or fix the bug, then verify it locally.
4. Commit. Stage the changes (add) and commit them with a meaningful message.
5. Sync. Pull other people's commits and resolve conflicts if any appear.
6. Publish. Run push and open a pull request for review.

Where beginners usually slip up

• One 3,000-line commit per week. Such history is unreadable and impossible to roll back partially. A commit should be one finished logical change.
• Messages like “fix”, “wip”, “123”. They are useless a month later. State what changed and why: Fix NPE in UserService when email is null.
• No .gitignore. Without it target/, *.class and .idea/ end up in the repository — noise, conflicts and extra megabytes.
• 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.
• Working only in main. An unfinished feature on the main branch blocks the release for the whole team.
• Careless git push --force to a shared branch. It rewrites history and wipes other people's commits — precisely the disaster version control was supposed to prevent.

Conclusion

A version control system is as basic a developer tool as an IDE or a build tool. Three things are worth remembering for practice and for interviews: a VCS stores the history of changes and lets you roll back; a CVCS keeps that history on the server while a DVCS gives every developer a full copy; and today's industry standard is Git, with GitHub being only a hosting service around it. The next step is to install Git and run one practice project through the full cycle: clone → branch → commit → push.