Free lesson · Git Mastery

What is Git?

Easy7 min readgit

What is Git?

A note from Olena Marchenko, Software Engineer II at Microsoft Azure DevTools, working on VS Code remote development and GitHub integration.

The Confusion Before the Clarity

When I started learning to code in 2018 - a 26-year-old financial analyst in Warsaw teaching herself web development from freeCodeCamp and The Odin Project - Git was the first tool that genuinely confused me. Not the syntax. The model. I kept hearing "Git is a version control system" and "GitHub is where you store your code" and I could not for the life of me tell which one I was using when I typed git push and my code appeared on a website.

If that confusion is yours right now, let me give you the single sentence that finally clicked for me, two months in:

Git is a program that lives on your computer and records snapshots of your project. GitHub is a website that hosts copies of those snapshots so other people can see them.

Git, the program, runs locally. It does not need the internet. It does not need GitHub. You can use Git for years on a project that never leaves your laptop, and it will work exactly the same as Git used by a thousand engineers collaborating on the Linux kernel.

This topic is about Git the program. What it actually is, what problem it actually solves, and why it has the strange mental model it does.

Interactive animation: Git is a program on your computer that records snapshots; GitHub is a website that hosts copies of them.

What Git Actually Does

Git is a version control system. The job of a version control system is to record the history of your files as they change over time, so you can:

Look at what your project looked like at any point in the past
Compare any two points in time and see what changed
Undo changes without losing the work that came after them
Work on multiple parallel versions of the project at once
Combine work from multiple people without overwriting anyone

Without version control, the closest you can get to history is saving copies of files with names like proposal_v3_final_FINAL.xlsx. I spent four years as a financial analyst doing exactly that, and the version chaos was constant. Files diverged. People emailed back different copies. Nobody knew which version had which change.

Version control fixes that by making history a first-class part of the project. Every change you record gets a unique identifier, a timestamp, an author, and a message describing why you made it. You can navigate that history like a tree, jumping between any two points and seeing exactly what's different.

The Snapshot Model

Most older version control systems - CVS, Subversion, Perforce - store history as a series of differences. The first version of the file is stored in full; every change after that is stored as "starting from version 1, change line 4 from X to Y." To reconstruct any version, the system has to apply all the differences in order.

Git took a different approach. Git stores history as a series of snapshots. Every time you record a change, Git takes a full snapshot of every file in your project and saves it. If a file didn't change between two snapshots, Git is smart enough to not store it twice - it just keeps a pointer to the previous version - but conceptually, each snapshot is the complete state of the project at that moment.

flowchart LR
    A[Snapshot 1<br/>file_a v1<br/>file_b v1<br/>file_c v1] --> B[Snapshot 2<br/>file_a v1<br/>file_b v2<br/>file_c v1]
    B --> C[Snapshot 3<br/>file_a v1<br/>file_b v2<br/>file_c v2]

This diagram shows Git's snapshot model. Each snapshot is a complete picture of the entire project at one moment. Snapshot one has the original version of three files. Snapshot two changes file b but file a and file c are identical to before. Snapshot three changes file c. Each snapshot is logically complete on its own, but Git stores the unchanged files only once internally, keeping it efficient.

This sounds like a small difference. It's not. The snapshot model is what makes Git fast at things older systems are slow at - branching, jumping between versions, comparing distant points in history. It's also why understanding Git is initially hard. Most newcomers were taught (or assumed) the diff model from earlier tools, and Git keeps surprising them.

Interactive animation: Older tools store a first version plus every difference; Git stores a full snapshot each time, unchanged files only once.

Three Things to Notice About Git

A few properties of Git that shape everything else in this course:

Git is distributed. Every copy of a Git repository is complete. Your local clone has the full history of the project - every snapshot, every author, every change message, all the way back to the beginning. This is unusual. In centralized version control, you can see only the latest version locally; you have to ask the server for anything older.

Git is content-addressable. Every snapshot, file, and metadata object in Git gets a unique ID derived from its contents. Change one character anywhere in the project and the resulting snapshot gets a completely different ID. This makes Git's history tamper-evident - you can't quietly rewrite history without it being obvious that something changed.

Git is fast. Most Git operations happen locally and complete in milliseconds. The few that talk to a remote server (push, pull, fetch) are slow only because of the network. Local history navigation, branching, and comparison are essentially instantaneous, even for repositories with decades of history.

What Git Is Not

To draw the boundary clearly:

Git is not GitHub. GitHub is one of many websites that host Git repositories. Other hosts include GitLab, Bitbucket, Azure DevOps, and your own server if you set one up.
Git is not a backup system. It records intentional changes that you ask it to record. If your laptop dies before you push to a remote, the work you didn't push is gone.
Git is not a project management tool. It tracks code changes. Issues, releases, milestones, kanban boards - those are features that hosting platforms layer on top of Git, but they're not Git itself.
Git is not a build system or test runner. It doesn't know whether your code compiles or whether your tests pass. It just records the state of your files.

When I Started Self-Teaching

The thing that helped me most was setting up a tiny project - a personal todo list in HTML and JavaScript - and using Git on it for two weeks before I ever pushed anything to GitHub. I made changes, committed them, looked at the history, undid things, made branches, threw the branches away. I broke things on purpose and recovered from them.

By the time I pushed to GitHub for the first time, I understood that GitHub was just a copy of what I already had locally. The mystery of "where does my code go when I push" disappeared. Git wasn't a magical cloud thing; it was a program on my laptop that happened to know how to talk to other Git repositories elsewhere.

That separation - Git the local program from GitHub the hosting service - is the single biggest mental shift for newcomers. The rest of this course builds on it.

What Comes Next

The next six topics finish the introduction. Topic 1.2 explains version control generally and why it matters. Topic 1.3 contrasts Git's distributed model against centralized systems like Subversion in more detail. Topic 1.4 covers the surprisingly dramatic origin story of Git itself. Topic 1.5 helps engineers migrating from other version control systems. Topics 1.6 and 1.7 walk through installation and configuration so you can actually start using Git on your own machine.

By the end of Module 1, you'll have Git installed, configured, and conceptually understood. Module 2 is where the actual commands begin.

What Goes Wrong

Warning: Common confusions when you're new to Git:

Treating Git and GitHub as the same thing. They are not. Git works fine without GitHub. GitHub without Git makes no sense.

Expecting Git to know what your code does. It records changes. It does not understand them. A commit that breaks every test in your project is still a valid commit.

Treating commits as save points like in a game. A commit is a deliberate, named record of a change - not an autosave. You decide when commits happen.

Believing Git protects against laptop failure. Until you push your work to a remote (Module 9), your history is on one machine only. Treat Git as version control, not backup.

Assuming a Git command will fix something it broke. Git is powerful but does not always have an undo for the specific shape of the mistake you just made. Module 5 covers what's recoverable.

Try It

Exercise: Before continuing, do these:

Open a terminal and type git --version. If you don't have Git installed, Topic 1.6 will walk you through it; come back here after.

Type git help. Skim the output. You don't need to memorize anything; just notice the scale of the surface area.

Open a project folder (any project - a school assignment, a recipe collection, anything with files). Look at it as it is now. Imagine the same folder six months ago. That mental gap is the problem Git solves.

In a sentence, explain to yourself the difference between Git and GitHub. If you can't, re-read the second paragraph of this topic.

Find a file on your computer that has a version history embedded in the filename (something like report_v2_FINAL.docx). Count how many copies exist of essentially the same file. That's what life without version control looks like.

Back to Git Mastery