Before we can understand what a commit does, we need to understand the problem it solves.

What is version control?

Version control is a system that tracks changes to files over time. Instead of having files named “essay_final.docx,” “essay_final_v2.docx,” and “essay_REALLY_final.docx” scattered across your desktop, a version control system keeps one file and remembers every state it has ever been in. You can jump back to any earlier state, compare two states side by side, or merge changes made by different people. Git is the most widely used version control system in the world today, and it is used by almost every major software company, from tiny one-person projects to organizations with tens of thousands of engineers.

Where does “commit” fit in?

Within Git, a commit is the basic unit of saved history. Every time you commit, you are telling Git: “take a snapshot of my project exactly as it looks right now, and remember it forever under this label.” Each commit becomes a permanent checkpoint that you, or anyone else working on the project, can return to at any time. Without commits, Git would have nothing to track — commits are the individual beads on the string that makes up your project’s entire history.

To understand committing, you first have to understand that Git keeps your files in three distinct places at once.

When you’re working on a project tracked by Git, a file can exist in one of three areas: the working directory, the staging area, and the repository. Understanding the journey a file takes through these three areas is the single most important mental model for understanding what a commit actually does.

The working directory

This is simply the folder on your computer where you edit files — the one you see in your file explorer or code editor. When you open a file and type new code, you are editing it in the working directory. At this point, Git has noticed the file changed, but has done absolutely nothing to save that change permanently.

The staging area

The staging area, sometimes called the “index,” is a waiting room. It’s where you tell Git, “these specific changes, out of everything I’ve edited, are the ones I want included in my next snapshot.” This is a uniquely powerful idea in Git: you don’t have to save every single change you’ve made in one go. You can edit ten files, but choose to stage and save only three of them, leaving the other seven for a later, separate snapshot.

The repository

The repository is the permanent, historical record. Once you commit, whatever was in the staging area gets copied into the repository as a new, permanent snapshot. Unlike the working directory or staging area, changes in the repository are not casually lost — they are part of the project’s recorded history from that point forward.

flowchart LR
    A["Working Directory
(you edit files here)"] -- "select changes" --> B["Staging Area
(changes waiting to be saved)"]
    B -- "commit" --> C["Repository
(permanent snapshot history)"]
    style A fill:#fafafa,stroke:#e5e5e5
    style B fill:#fef2f2,stroke:#dc2626
    style C fill:#111111,stroke:#111111,color:#ffffff
        

Committing feels like a single instant action, but internally, Git performs several precise steps in sequence.

When you trigger a commit, Git doesn’t just make a vague note that “something changed.” It performs a very specific, mechanical process behind the scenes, and understanding this process demystifies a lot of what feels like Git “magic.”

A commit is more than just “saved files.” It’s a small, structured record with several distinct parts.

Every commit Git creates carries a fixed set of information. Understanding these parts helps you read commit history, use tools like blame and log effectively, and understand exactly what evidence a commit leaves behind.

A single commit is useful, but the real power of Git comes from how commits connect to each other.

Because every commit stores a reference to its parent, Git doesn’t just hold a pile of unrelated snapshots — it holds a connected chain. Starting from the very latest commit, you can walk backward through the parent references, commit by commit, all the way back to the very first commit ever made in the project. This chain is what people mean when they talk about “commit history” or “the log.”

gitGraph
   commit id: "Initial setup"
   commit id: "Add login page"
   commit id: "Fix login bug"
   branch feature
   checkout feature
   commit id: "Add signup form"
   checkout main
   commit id: "Update README"
   merge feature id: "Merge signup feature"
        

Branches are just labels on commits

A branch, such as “main,” is really just a movable label pointing at a specific commit — usually the latest one on that line of work. When you commit, Git moves that label forward to the new commit automatically. This is why creating a new branch is so cheap and fast in Git: you’re not copying the whole project, you’re just creating a new label that points at the same commit as the branch you started from.

The message attached to a commit is, arguably, just as valuable as the code change itself.

A commit without a meaningful message is like a photograph with no caption, taken by someone else, found years later — you can see what it shows, but you have no idea why it was taken or what it meant to the person who took it. In a professional codebase, developers rely heavily on commit messages to understand the reasoning behind changes, especially long after the original author has forgotten the details or moved to a different project entirely.

What makes a good commit message

A strong commit message typically has a short summary line — usually under about fifty characters — that describes what changed, written as if completing the sentence “This commit will…” For example, “fix null pointer error on empty cart” is far more useful than “fixed bug” or “updates.” If more context is needed, a longer explanation can follow, describing why the change was necessary, what alternatives were considered, or what problem it solves.

Not every commit looks the same. Recognizing these common patterns helps you read a project’s history fluently.

Almost everyone learning Git makes these same handful of mistakes early on. Recognizing them speeds up the learning curve considerably.

A handful of simple habits separate a messy, unreadable history from a clean, trustworthy one.

Commits aren’t just a beginner exercise — they’re the backbone of how modern software is actually built at every scale.

Large open-source projects rely almost entirely on commit history to coordinate the work of thousands of independent contributors. The Linux kernel, one of the largest and longest-running software projects in the world, has accumulated well over a million commits across its history, each one a discrete, attributable change reviewed and merged into the project. Every one of those commits carries an author, a message, and a place in the chain — exactly the same fundamental structure a beginner’s very first commit has.

No. Committing only saves a snapshot inside your local repository, on your own computer. Sharing that history with a remote server, like one hosted online, is a separate, later step.

Yes. Git provides several ways to undo or reverse a commit’s effects, ranging from quietly rewriting recent history to creating a new commit that explicitly cancels out an earlier one, preserving the full record.

Git will refuse to create a commit if nothing has been staged, since there would be no new snapshot content to save. You must stage at least one change before committing.

No. Saving a file only updates it on your disk in the working directory. Committing is a separate, deliberate action that permanently records a snapshot of your staged changes into the project’s history.

In practical terms, no. The hash is calculated from the commit’s exact contents, and the chance of two different commits producing the same hash is astronomically small — small enough to be treated as effectively impossible.

A merge commit represents the point where two separate lines of history come together. It needs a reference to both parent lines so Git can accurately reconstruct how the two branches’ changes were combined.

No. You can save a file many times while working, and only commit once you’ve reached a meaningful, coherent checkpoint worth recording permanently in history.

Committing is the single action that transforms your in-progress edits into a permanent, labeled, recoverable part of your project’s history. It moves whatever you’ve deliberately staged from the temporary working directory into a durable snapshot inside the repository, complete with a unique fingerprint, a link back to the commit before it, and a message explaining what changed and why. Understood this way, a commit isn’t just a technical checkpoint — it’s a small act of documentation, one that, repeated thousands of times across a project’s life, becomes the complete, trustworthy story of how that project came to be.