What Git Is
Git is a version control system, but the useful mental model is sharper than that: Git records named snapshots of your project, links them into history, and lets every clone carry the whole repository.
Version control, not just backup
Version control records how a set of files changes over time so you can inspect, compare, recover, and explain earlier versions. A backup answers "can I get a copy back?" Git answers more useful questions: What changed? Why did it change? Who changed it? Which version introduced the bug? Can I try a risky idea and return to the clean state afterward?
The simplest version control system is a folder full of copies: project-final, project-final-2, project-final-real. That works for a moment, then collapses because the names describe your anxiety more than the project. Git replaces those copies with a structured history. Each meaningful state gets a commit message, an author, a timestamp, and a stable identifier.
Git is a distributed version control system. It stores a local database of project history, lets you create commits from selected changes, and can exchange that history with other repositories.
That phrase "selected changes" is doing real work. Git is not merely an automatic save system. You decide when a state deserves to enter history, and you decide what belongs in that state. That choice is why good Git history can read like a trail of design decisions instead of a pile of accidents.
Snapshots, not loose diffs
Many version control explanations start with diffs, and diffs matter: git diff shows line-by-line changes. But Git's deeper storage model is snapshot-based. When you commit, Git records a snapshot of the project tree as it should look at that moment. If a file is unchanged from a previous commit, Git can reuse the existing stored content instead of storing a duplicate.
This means a commit is closer to "the project looked like this" than "apply these edits." Git can still compute the difference between any two commits, but the difference is derived from snapshots rather than being the only thing Git knows.
A diff is how you inspect a change. A commit is the stored project state plus metadata. Keeping those separate makes commands like git diff, git show, git checkout, and git restore much easier to reason about later.
Distributed repositories
Git is distributed because a normal clone includes the repository history, not just the latest files. Your laptop has enough information to inspect old commits, create new commits, branch, merge, compare versions, and recover committed work without asking a central server for permission.
Services like GitHub are important, but they are not Git itself. GitHub hosts repositories, coordinates collaboration, runs reviews, and provides web tools. Git is the version control system underneath. A remote repository is another copy you can fetch from and push to; it is not the only place where history lives.
| Centralized habit | Git habit |
|---|---|
| The server is the project history. | Each clone has a useful copy of the history. |
| You need the server for most historical operations. | Reading history, committing, branching, and diffing are local. |
| Collaboration means checking files out from one central place. | Collaboration means exchanging commits between repositories. |
This local-first model is why Git feels fast and why it can support different workflows. A solo project, a class assignment, an open source pull request, and a large company monorepo can all use the same core ideas, even if their publishing rules differ.
Commits as content-addressed history
A commit is a snapshot plus context. It points to a project tree, names its parent commit or commits, records author and committer metadata, and stores a message. Git identifies stored objects by checksums derived from their content. That is why commit identifiers look like long hexadecimal strings.
You usually see shortened IDs, but they refer to longer object names:
24b9da6 Add parser tests for empty inputThe exact identifier is not just a serial number. Change the content or metadata and the identity changes. That property gives Git a strong integrity model: history is made of objects whose names depend on what they contain.
Commits also link backward. A normal commit stores its parent, so history forms a chain. A merge commit can store more than one parent, so history can become a graph. You do not need the internals on day one, but you do need this idea: Git history is not a folder of file copies. It is a graph of named snapshots.
The three local areas
Most beginner confusion comes from expecting Git to have only two places: your files and the saved history. Git has a third place in between.
| Area | What it means | Typical command |
|---|---|---|
| Working tree | The files checked out on disk. This is where you edit. | git status, git diff |
| Staging area | The proposed contents of the next commit. Git also calls this the index. | git add, git diff --staged |
| Repository | The local database of committed snapshots and metadata, stored under .git. |
git commit, git log |
The staging area is not a bureaucratic extra step. It lets you separate "what I have changed in my editor" from "what belongs in the next coherent commit." That is why you can edit three files but commit only the two lines that complete a small fix.
git status
git diff
git add README.md
git diff --staged
git commit -m "Explain project setup"Why the model matters
Git commands become less mysterious when you map each one to the model. git status asks where files differ across the working tree, staging area, and repository. git add copies selected content into the staging area. git commit turns the staging area into a new snapshot in the repository. git log reads the chain of commits. git diff compares two states.
That means the daily question is not "did I save?" Your editor saves files. Git asks, "Which version of this project deserves a name in history?" You can work messily in your working tree, then stage carefully. You can inspect what you are about to commit before creating history. You can commit locally before you publish. Those separations are the center of Git's power.
Committing is local. Pushing is publishing to another repository. You can make several thoughtful local commits before any remote service sees them.
Common pitfalls
Thinking GitHub and Git are the same thing. Git works locally. GitHub is a hosting and collaboration platform. When a command behaves oddly, first ask whether you are dealing with local history or a remote service.
Treating the staging area as automatic. A file can be modified but not staged, staged but edited again, or committed. Always check git status and git diff --staged before committing.
Assuming uncommitted work is protected like committed work. Git is very good at preserving committed snapshots. Uncommitted edits are easier to overwrite, delete, or tangle. Commit good checkpoints before experiments.
Making commits mean "everything I changed today." A useful commit is a coherent project state with a reason. Smaller commits are easier to review, revert, and understand.
Worked examples
Example 1: Is this a backup, a commit, or a snapshot?
You copy site to site-old before trying a redesign. That is a backup copy: it may save you once, but it has no structured history, no message, no author, and no easy way to compare intent.
You run git commit -m "Simplify homepage layout" after staging the intended files. That creates a commit: a named snapshot in the repository, linked to its parent and available for comparison later.
Example 2: Why can Git show a diff if it stores snapshots?
Imagine commit A stores README.md with one paragraph and commit B stores the same file with two paragraphs. Git can compare the two snapshots and compute the added lines on demand. The diff is the comparison result, not necessarily the primitive thing Git saved as history.
git diff A B -- README.mdExample 3: Where is my change right now?
If you edit README.md, the change starts in the working tree. After git add README.md, the current content of that file is staged. If you edit the file again, you now have two versions to think about: the staged version and the newer working tree version.
git diff
git diff --stagedThe first command shows unstaged edits. The second shows what would enter the next commit.
Example 4: Why can you commit offline?
A commit writes to your local repository. It does not require GitHub, a school server, or a network connection. Later, when you run git push, you ask another repository to receive commits you already made.
This is the distributed model in everyday form: commit locally, publish when you are ready, fetch when you want to learn what someone else published.
Sources & further reading
-
Primary explanation of Git's snapshot model, local operations, integrity model, and three file states.
-
Background on local, centralized, and distributed version control systems.
-
Deeper look at the object database behind blobs, trees, commits, and content-addressed storage.
-
Official command reference for Git. Use it when you need exact command behavior and options.
-
GitHub's beginner-oriented framing of Git, repositories, commits, branches, and remotes.