What Is a GitHub Commit? A Plain-English Guide

The short answer: A GitHub commit is a saved snapshot of changes to a project's code, bundled with a short message that describes what changed. Think of it as a labeled save point. Every time a developer finishes a piece of work, they "commit" it, which records exactly what was added, removed, or modified, along with who did it and when.

That's the one-sentence version. Below is the plain-English version, with no coding knowledge assumed.

What a commit actually is

Imagine writing a document, but every time you save, the program keeps a permanent copy of that exact version, forever, with a note explaining what you just changed. You could scroll back through every save and see how the document evolved, who changed what, and why.

That's basically what a commit is, but for code.

When developers work on software, they make changes to files: adding new features, fixing bugs, tidying things up. A commit is the act of saving a batch of those changes as a single, permanent record. Each commit captures three things: what changed, who changed it, and a short message describing the change.

GitHub is the website where these commits are stored and shared, so a "GitHub commit" is simply a commit that lives in a project hosted on GitHub. (The underlying technology is called Git. GitHub is the popular service built on top of it. People use the terms loosely, but that's the distinction.)

What's inside a commit

Every commit has a few standard parts. You don't need to memorize these, but seeing them named makes the rest of this clearer.

There's the commit hash, a long string of letters and numbers like a1b2c3d that acts as the commit's unique ID. You can safely ignore it; it's just how Git tells one commit from another.

There's the author and timestamp, which record who made the change and exactly when.

There's the commit message, the short, human-written note describing what changed. This is the part you'll actually read.

And there's the diff, which is the actual list of lines of code that were added or removed in that commit. This is the technical heart of it, and the part non-developers usually skip.

So a single commit might read as: hash a1b2c3d, by Sara, on Tuesday, message "fix login button on mobile," containing 12 lines changed across 2 files.

What a commit message looks like

The commit message is where most of the confusion starts, so let's look at a real one.

A typical message looks like this:

fix: login button not working on mobile

The part before the colon (fix) is a category. The part after it is a plain description of what changed. Developers follow a loose convention where the first word signals the type of work. Once you know the common ones, you can read most commit messages at a glance:

feat means a new feature was added. fix means a bug was fixed. chore means routine maintenance with no visible change for users. refactor means the code was reorganized or cleaned up without changing what it does. docs means documentation was updated. test means tests were added or changed. And wip, short for "work in progress," means the work isn't finished yet.

So a message like feat: add Google login means "a new feature was added: users can now log in with Google." And chore: update dependencies means "routine maintenance; nothing changed for users."

Not every developer follows this convention, and some write vague messages like misc fixes or just wip, which is exactly why commit messages can be frustrating to read. But when the convention is followed, it's a quick way to understand what happened.

Why commits exist at all

Commits might seem like extra bookkeeping, but they solve real problems.

They create a full history. Because every commit is permanent, a project has a complete, timestamped record of every change ever made. If something breaks, developers can look back and find exactly which commit caused it.

They make it possible to undo. Since each commit is a snapshot, developers can roll the project back to an earlier commit if a change goes wrong, like an unlimited undo button.

And they let people work together. On a team, several developers change the same project. Commits keep everyone's work organized, attributed, and mergeable, so two people editing the same code don't overwrite each other.

In short, commits are what turn "a folder of code files" into a trackable, reversible, collaborative project.

How to look at commits on GitHub

If you want to see the commits in a project yourself, it's straightforward.

Open the project (called a repository, or "repo") on GitHub. Near the top of the file list, you'll see a small clock or history icon with a number next to it, something like "1,248 commits." Click it. You'll get a reverse-chronological list of every commit: the message, who made it, and when. Click any single commit and GitHub shows you the diff, the exact lines that were added (in green) and removed (in red).

That's the whole mechanic. The list is the history; each entry is one saved change.

A quick note if you're not a developer

If you found your way here because you're a founder or manager trying to understand what your developers are doing, here's the honest truth: knowing what a commit is only gets you halfway.

The harder problem is that commit messages are written by developers, for developers. A message like fix: refactor auth middleware jwt validation is technically a perfect commit message, and it still tells you nothing about whether your login system works. The convention helps you categorize the work, but it rarely tells you what changed for your users or your business.

If that's the gap you're trying to close, reading commits one by one isn't really the answer. We wrote a separate, founder-focused guide on exactly this: how to understand GitHub commits in plain English, which covers how to translate developer shorthand into the business updates you actually care about.

Frequently asked questions

What does "commit" mean in GitHub? To commit means to save a batch of code changes as a permanent, labeled record. The resulting commit captures what changed, who changed it, when, and a short message describing it.

What is the difference between a commit and a push? A commit saves changes locally as a snapshot. A push uploads one or more commits to GitHub so others can see them. You commit first, then push.

What is a commit message? A commit message is the short, human-written note attached to a commit that describes what changed, for example "fix: login button not working on mobile."

Is a commit the same as saving a file? It's similar but more powerful. A normal save overwrites the previous version. A commit keeps every version permanently, with a description and author, so the full history is preserved and reversible.

What does "wip" mean in a commit? WIP stands for "work in progress." It signals that the work in that commit isn't finished yet.