Free lesson · Git Mastery

Version Control Basics

Easy7 min readgit

Version Control Basics

A note from Olena Marchenko, Software Engineer II at Microsoft Azure DevTools.

Why Version Control Exists

Before I learned to code, I spent four years as a financial analyst in Warsaw. I worked in Excel and PowerPoint mostly, building quarterly reports and forecasting models for a Big Four firm. There was no version control in that world. Every report I shipped had a filename like Q3_Forecast_v7_postmeeting_FINAL_OM_edits.xlsx. When I changed companies, my new firm used a shared network drive where the convention was to append your initials and a date to every file you touched. I once watched two senior analysts argue for forty-five minutes about which of seven versions of a file was the actual current one.

That world is what software engineering looked like before version control. People worked in their own copies, emailed updates around, and tried to keep track manually of who had changed what. It worked until it didn't, which was often.

Version control is the engineering answer to that chaos. The job of a version control system is to make the history of changes to a project explicit, navigable, and shareable. Once you have it, you stop renaming files. You stop emailing copies. You stop wondering which version is current.

What a Version Control System Provides

Every version control system, regardless of how it's implemented, provides three things:

A timeline of changes. Every change to the project is recorded with its author, a timestamp, and a message explaining the change. You can scroll back through the history at any point and see what the project looked like.

The ability to undo. Any past version can be recovered. You can throw away a change you regret without losing the work that came after. You can compare any two points in the history and see exactly what's different.

A way to coordinate. Multiple people can work on the project in parallel, then combine their changes safely. The system understands which changes happened in which order and which conflict with each other.

These three capabilities together change how teams work. They make experimentation safe (you can always roll back), they make collaboration possible (people can work in parallel), and they make accountability possible (every line of code has a recorded author and reason).

Three Kinds of Version Control

Version control systems have evolved through three generations.

flowchart TD
    A[Local VCS<br/>RCS, SCCS<br/>History on one machine] --> B[Centralized VCS<br/>CVS, SVN, Perforce<br/>History on shared server]
    B --> C[Distributed VCS<br/>Git, Mercurial<br/>Full history on every machine]

This diagram shows three generations of version control. Local systems like R C S and S C C S stored history on one machine only - useful for solo work, useless for teams. Centralized systems like C V S, Subversion, and Perforce moved history to a shared server everyone connects to - solved teamwork but introduced new problems like server downtime and slow operations. Distributed systems like Git and Mercurial give every machine a full copy of history - fast, offline-capable, and resilient. Git is the distributed system this course covers.

Local version control was the first generation. Tools like RCS (1982) kept a database of changes alongside the files on a single machine. They were useful for solo developers tracking their own work but useless for teams.

Centralized version control put the history on a shared server. CVS (1990), Subversion (2000), and Perforce (1995) follow this model. Everyone connects to the server to record changes or fetch updates. This makes teamwork possible but creates dependencies - if the server is down, nobody can record work. Operations are slow because they go over the network. And history exists in only one place: lose the server without backups and the project's past is gone.

Distributed version control gives every user a complete copy of the project's history. Git (2005) and Mercurial (2005) are the dominant examples. Every clone is a backup. Most operations are local and instant. Network access is only needed to share changes with other clones. Topic 1.3 covers this distinction in more detail.

Core Concepts You'll Encounter

A vocabulary of concepts that show up in every version control discussion:

Repository (repo). The container that holds a project's files and the complete history of changes to those files. A repository can live on one machine, on a server, or both.

Commit. A single recorded change. A commit captures the state of all tracked files at one moment, plus metadata: who made the change, when, and a message explaining why. Commits form the timeline.

Branch. A parallel line of development. Branches let multiple changes happen at the same time without interfering. You might have a main branch for stable code and a feature/login branch where you're working on a new login flow.

Merge. Combining two branches into one. The system figures out which changes happened on each branch and produces a unified result. Sometimes this is automatic; sometimes you have to resolve conflicts - places where the same file changed in incompatible ways on both branches.

Remote. Another copy of the repository, usually on a server. You push your local changes to a remote to share them, and pull changes from the remote to receive other people's work.

Working directory. The actual files on your disk that you edit. This is separate from the recorded history - your working directory can have uncommitted changes that exist nowhere else.

This vocabulary is universal across version control systems. Even if you'd never used Git, you'd encounter these concepts in any other VCS.

What Version Control Doesn't Do

A few things people sometimes expect from version control that it doesn't actually provide:

It doesn't enforce code quality. A commit that adds a bug is still a valid commit. A commit that breaks every test is still a valid commit. Quality enforcement lives in adjacent tools - linters, tests, CI systems, code review - that are run on top of version control.

It doesn't document why decisions were made beyond the commit message. If your team makes a structural choice and writes only one-word commit messages about it, the reasoning is lost. The version control system records what changed, not what was discussed.

It doesn't protect you from yourself. You can force-push and overwrite history. You can delete branches. You can rewrite the past in ways that lose work. Version control systems give you the ability to undo many mistakes, but not all.

When I Was Learning This

The mental shift that took me longest as a self-taught engineer was realizing that version control isn't optional for "serious" projects. It belongs on every project from day one, even tiny personal ones. Once you internalize that, you start using git init on every new folder you create - recipes, blog posts, presentations, code. The cost of starting with version control is fifteen seconds. The cost of adding it three months in is much higher because you've lost the early history.

A specific habit I picked up at Zalando in London - my first real engineering job in 2020 - was using version control even for small one-off scripts. My team had a rule: if you wrote it twice, it goes in a repo. The reasoning was that anything used twice eventually needs to be modified, and modifying without history is how regressions happen.

That habit moved with me to Microsoft. Even the throwaway tools I write on the Azure DevTools team for one-time data inspection live in tiny git repositories somewhere. The repository is free; the regret of not having one is real.

What Comes Next

Topic 1.3 contrasts Git's distributed model against centralized systems in more detail - useful even if you've only ever used Git, because the comparison reveals why Git makes certain design choices that feel strange at first.

Topic 1.4 covers Git's specific history: the dramatic 2005 origin story tied to the Linux kernel and a license dispute that shaped what Git became.

Topic 1.5 is specifically for engineers migrating from other VCS systems - SVN, Perforce, Mercurial. If that's you, skip to it after Topic 1.4.

What Goes Wrong

Warning: Newcomer mistakes with the concept of version control:

Treating it as optional for "small" projects. Small projects grow. The history you didn't record on day one is gone forever.

Confusing version control with backup. They are different things. Version control records intentional changes; backup protects against device failure. Use both.

Believing commit messages don't matter. Six months from now, your past self is a stranger. The commit message is the only context that stranger has.

Recording massive commits that change everything. A commit should record one logical change. Topic 2.6 covers commit messages and atomic commits in depth.

Avoiding branches because they feel scary. In Git, branches are nearly free. Module 6 covers them in detail. Use them.

Try It

Exercise: Practice the mental model:

1. Pick one file in your work that has been edited at least ten times in the last month. List the changes you remember. Notice how few you can actually recall.
2. Open a folder on your computer with file names containing version markers like _v2, _final, _revised. Count them. That's the chaos version control eliminates.
3. Without coding, sketch a timeline of your last project's major changes. What would the commits have been if you had been using version control from the start?
4. Look up the size of the Linux kernel repository on GitHub. Note how much history exists. Now think about navigating that without version control.
5. List three things you'd want to be able to do with your project's history - find when a bug was introduced, see what changed last week, find who wrote a specific function. Version control is what makes those possible.

Back to Git Mastery