Version Control: Commits, Branches & Workflows

Q: What's the difference between centralized and distributed version control?

In centralized systems (SVN), a single server holds the authoritative history and developers check out working copies — simple, but you need server access to commit or view history, and the server is a single point of failure. In distributed systems (Git, Mercurial), every clone contains the complete history, so you can commit, branch, diff, and explore history entirely offline; the shared "remote" is a convention for collaboration, not a requirement. Distributed won because it's faster, works offline, and makes branching/merging cheap — which is why Git is everywhere.

Version Control

Version control is a system that records changes to your code over time, so you can see what changed, who changed it, when, and why — and roll back, branch, and collaborate without stepping on each other. It is the single most essential tool in software development: every serious project uses it, and working without it is like writing without an undo button or a save history.

In practice, "version control" today overwhelmingly means Git, the distributed system that became the universal standard. This page covers the concepts — commits, branches, merges, history, and workflows — that apply across any version control system, with Git as the concrete example. Master the concepts and the specific commands follow.

TL;DR

A version control system (VCS) tracks changes to code over time — history, blame, rollback.
It enables collaboration without overwriting each other's work.
Core concepts: commit, branch, merge, history, remote.
Git is the universal standard (distributed); platforms (GitHub/GitLab) host it.

Quick Example

The everyday version-control loop, in Git:

Why Every Project Needs It

History — every change is recorded, so you can see how the code evolved and why (commit messages).
Undo / rollback — revert to any previous state; mistakes aren't catastrophic.
Collaboration — many people work in parallel and merge their changes safely.
Branching — develop features, fixes, and experiments in isolation without breaking main.
Accountability — blame shows who changed each line, aiding debugging and review.

Even a solo project benefits enormously — it's your safety net and your changelog.

Core Concepts

Repository — the project plus its full change history.
Commit — a recorded snapshot with a message explaining the change. The atomic unit of history.
Branch — an independent line of development; you branch to work in isolation, then merge back.
Merge — combine changes from one branch into another (sometimes with conflicts to resolve).
Remote — a hosted copy (on GitHub/GitLab) you push to and pull from to collaborate.
History — the ordered graph of commits; you can inspect, search, and revert it.

See Git for the commands behind each.

Centralized vs Distributed

Centralized (CVCS) — older model (SVN): one central server holds the history; clients check out working copies. Simpler, but the server is a single point of failure and offline work is limited.
Distributed (DVCS) — Git, Mercurial: every clone has the full history. You commit, branch, and view history offline; the "central" remote is a convention, not a requirement. This model won — Git is distributed.

Workflows

Teams adopt a branching workflow to stay coordinated:

Trunk-based — short-lived branches merged frequently into main; pairs with CI/CD.
Feature branch / GitHub Flow — a branch per feature, merged via pull request after review.
Git Flow — structured long-lived branches (develop/release/hotfix); heavier, for scheduled releases.

💡 Most modern teams use short-lived feature branches + pull requests + CI — simple, reviewable, and fast. See Git.

Best Practices

Commit often, in logical units — small, focused commits with clear messages.
Write meaningful commit messages — explain why, not just what.
Branch for isolated work and merge via pull requests with review.
Pull/rebase frequently to avoid large, painful merges.
Never commit secrets — use Secrets Management; a leaked secret in history must be rotated.

Common Mistakes

Giant, vague commits

Committing secrets or generated files

FAQ

Is version control the same as Git?

No — version control is the general concept (tracking changes over time), and Git is one implementation of it, albeit the dominant one. Other systems exist (Mercurial, Subversion/SVN, Perforce), and the core ideas — commits, branches, merges, history — apply across all of them. In practice, "version control" and "Git" are used almost interchangeably today because Git won the standardization battle, but the concepts on this page transfer to any VCS. Learn the concepts; Git is where you apply them.

What's the difference between centralized and distributed version control?

In centralized systems (SVN), a single server holds the authoritative history and developers check out working copies — simple, but you need server access to commit or view history, and the server is a single point of failure. In distributed systems (Git, Mercurial), every clone contains the complete history, so you can commit, branch, diff, and explore history entirely offline; the shared "remote" is a convention for collaboration, not a requirement. Distributed won because it's faster, works offline, and makes branching/merging cheap — which is why Git is everywhere.

What is a branch and why use one?

A branch is an independent line of development that lets you work on a feature, fix, or experiment without affecting the main codebase. You create a branch, make commits in isolation, and merge it back when ready (typically after review via a pull request). Branches make parallel work safe — multiple people (or features) progress simultaneously without overwriting each other — and keep main stable and releasable. Cheap, fast branching is one of Git's defining strengths and the foundation of modern team workflows.

Do I need version control for a solo project?

Yes — the benefits aren't only about collaboration. Even solo, version control gives you a complete history (see how and why the code evolved), a safety net (revert any mistake to any prior state), the ability to branch for experiments without risking working code, and a backup when you push to a remote. It costs almost nothing to set up and saves you the moment something breaks or you need to recover earlier work. Treat git init as the first step of any project, however small.