Git: The Mental Model

You've probably typed these commands hundreds of times:

1git add .
2git commit -m "Fix something"
3git push
Copy

And most days, everything works.

Until it doesn't.

Suddenly, you're searching for the difference between reset and revert, wondering why your branch is behind, or asking the timeless developer question:

"Where did my changes go?"

The problem isn't that Git has too many commands. It's that we often learn the commands before understanding the ideas behind them.

Let's fix that.

1. What exactly is Git?

Git is a version control system. It records the history of a project so you can understand what changed, compare versions, work on different features, and recover from mistakes.

Imagine you're building a web application.

On Monday, the login page works.

On Tuesday, you add password validation.

On Wednesday, you refactor the form and accidentally break everything.

Without version control, you might be searching through old files named:

login-final.js
login-final-v2.js
login-final-actually-final.js

We've all seen this movie. Nobody likes the sequel.

Git gives your project a structured history instead.

You can save meaningful checkpoints, inspect changes, and return to earlier versions when necessary.

2. A repository is your project's history

A Git repository contains the information Git needs to track your project and its history.

When you initialize Git in a project, you create a repository:

1git init
Copy

Git creates a .git directory that stores repository data, including commits, references, and configuration.

Your source files remain ordinary files in your working directory. Git uses the repository to track their versions and relationships over time.

Think of it this way:

Working directory: Where you edit your files.

Repository: Where Git stores its version history and related data.

Commits: Checkpoints in that history.

One important detail: git init doesn't automatically commit your existing files. It initializes a repository; you still need to stage and commit the files you want to record.

3. A commit is more than a save button

A commit records a snapshot of the project as represented by the Git index at that moment.

For example:

1git add index.js
2git commit -m "Add login validation"
Copy

The first command stages the current content of index.js. The second records a commit using the staged content.

Later, you might change the file again and create another commit.

Your history could look like this:

A --- B --- C

Each letter represents a commit. The sequence shows how the project developed.

Here's the interesting part: Git does not simply make a full duplicate of every file for every commit. It stores content-addressed objects and represents project snapshots efficiently, reusing identical content where possible.

You don't need to memorize the storage internals yet. Just remember this:

A commit records a project snapshot and connects it to the project's history.

That mental model will help when we explore branches and merges.

4. Git has three important areas

Before we go further, understand these three concepts:

Working directory

This is where you edit files, add functions, fix bugs, and occasionally create new bugs.

Staging area

This is where you choose which changes should go into your next commit. It is also called the index.

Repository history

This is where your completed commits are recorded.

The basic flow looks like this:

Working Directory
|
| git add
v
Staging Area
|
| git commit
v
Repository History

Suppose you edit two files:

login.js — fixes a security issue.

README.md — updates documentation.

You can stage only the login fix:

1git add login.js
2git commit -m "Fix login validation"
3
Copy

The documentation change remains unstaged.

That's useful because a commit can contain one logical change instead of every modification you've made that afternoon.

And that's why ```git add .``` isn't always the best habit. Sometimes, a little selectivity saves a lot of confusion.

5. Git is not the same as GitHub

This distinction matters.

Git is the version control system.

GitHub is a hosting and collaboration platform built around Git repositories. GitLab and Bitbucket offer similar repository-hosting capabilities.

You can use Git entirely on your own computer without GitHub or an internet connection.

When you eventually push your commits to a remote repository, other developers can access the shared history, subject to the repository's permissions and workflow.

We'll explore how that works later in this series.

6. The mental model to remember

If you remember only these ideas from this article, you're in good shape:

A repository tracks your project's version history.

A commit records a snapshot based on staged content.

The staging area lets you choose what goes into the next commit.

Git's history connects commits together.

Git is the version control system; GitHub is one platform that hosts Git repositories.

Once these concepts click, commands stop feeling like mysterious instructions and start making sense as operations on a system you understand.

What's next?

In the next article, we'll create a small repository and follow a real change through git init, git add, and git commit.

We'll see exactly what happens at each step—and why staging is one of Git's most useful features.

Because understanding what you're committing is better than hoping your commit worked.

Next: git init, git add, and git commit Explained.