A commit in Git is a saved snapshot of your project at a point in time. When you run git commit, Git records the full state of your tracked files, along with who made the change, when, and a message saying why. It's not just a record of the lines you edited; per the Pro Git book, Git stores a snapshot of the whole project, not the differences. Each commit gets a unique hash computed from its content, so you can always return to that exact state, and any tampering is easy to spot. Commits link to their parent commits, forming the chain of history you can browse, undo, branch from, and share. Committing is local: it saves to your own repository, and you push separately to send commits to others. This guide explains what a commit records, how it's created, and how commits build a project's history.
Key takeaways
- A commit is a snapshot of your tracked files at a point in time, not just the changed lines.
- It records a tree (the snapshot), parent commit(s), author and committer, and a message.
- Each commit has a unique hash computed from its content, which makes it tamper-evident.
- Commits link through parent pointers to form the project's history.
- Committing is local; you stage with git add, commit, then push to share.
Quick explanation
In simple terms
A commit is like a save point for your whole project. It captures what all your tracked files look like right now, with a note about what you did, so you can come back to it later.
Technical definition
A commit is an immutable object in Git's object database that points to a root tree (the project snapshot) and to its parent commit or commits, and stores author, committer, and message metadata. It is identified by a hash of its content.
Analogy
Think of a commit like a numbered photograph of your entire project. The photo captures everything as it is right now, the number is unique to that exact shot, and each photo notes which one came before it, so the album tells the whole story in order.
Core concepts
A commit is a snapshot, not a diff
A commit stores the full state of your tracked files at a point in time, not just the changes.
This is the idea that surprises people coming from older tools. Systems like Subversion or CVS store the differences between one version and the next. Git does not. Per the Pro Git book, each commit points to a tree that captures the whole project as it looked at that moment.
Git stays efficient by storing each unique file once and reusing it. Unchanged files in a new commit point to the same stored content as before, so a snapshot of the whole project doesn't mean copying everything each time. When you view a diff, Git computes it on the fly by comparing two snapshots.
Example
Commit two files, change one, and commit again; the new commit reuses the unchanged file's content.
Why it matters — This snapshot model shapes how branching, merging, and reverting work, so it's the key idea to grasp first.
What a commit records
A commit stores a tree, parent commit(s), author and committer details, and a message.
A commit object is small but complete. It records a pointer to a tree, which is the snapshot of your project's top-level directory. It records one or more parent commits that link it to history. And it records the author and committer, each with a name, email, and timestamp, plus your commit message.
The author is who wrote the change; the committer is who created the commit. They're usually the same, but differ in cases like applying someone else's patch or rebasing. All of this comes together to describe not just what the project looked like, but who saved it, when, and why.
Example
A commit shows tree, parent, author, committer, and message when you run git show on it.
Why it matters — Knowing what a commit records explains what you can trust it for and why its hash changes.
The commit hash
Each commit has a unique hash computed from its content, used as its name and integrity check.
Every commit is identified by a hash, the long hex string you see in git log. It isn't a random ID from a database. Git computes it from the commit's content: the tree, the parent hash, the author and committer details, and the message. Git uses SHA-1 by default, with SHA-256 in newer versions.
Because the hash comes from the content, the same content always produces the same hash, and changing anything produces a different one. That makes commits tamper-evident. It also explains why amending or rebasing a commit gives it a new hash: you changed part of what was hashed.
Example
Amend a commit message with git commit --amend, and the commit's hash changes.
Why it matters — The hash is how Git names, links, and verifies commits, so it underpins Git's integrity.
Parents and the commit history
Commits link to their parents to form the project's history as a directed graph.
Each commit points back to its parent, the commit that came before it. This chain of pointers is your project's history. The very first commit has no parent and is called a root commit. A merge commit has two or more parents, because it joins separate lines of work.
Together these links form a directed acyclic graph, or DAG, rather than a simple straight line. That structure is what lets Git support branching and merging: development can split into parallel paths and come back together, and the history records exactly how.
Example
A merge commit lists two parents, one from each branch being merged.
Why it matters — The parent links are the history itself, so they explain how branching and merging work.
The staging area decides what goes in
A commit captures what you've staged with git add, not everything in your working directory.
A commit doesn't just grab whatever is in your folder. It captures what you've placed in the staging area, also called the index, using git add. This lets you choose exactly which changes go into a commit, even splitting the edits in one file across separate commits.
Anything you haven't staged, and any untracked or ignored files, won't be in the commit. This is why a commit can leave out changes you made: they simply weren't staged. The staging area is the checkpoint between editing and committing.
Example
You edit three files but git add only one; the commit includes just that one file's changes.
Why it matters — Understanding staging prevents the common surprise of a commit missing your latest edits.
Committing is local and permanent
A commit saves to your own repository and stays in history; sharing needs a separate push.
Making a commit writes to your local repository. It doesn't touch a server or teammates until you run git push. This is why you can commit offline and as often as you like: the work is safe in your own history first.
Once made, a commit is permanent in the sense that it stays in history and can be returned to. You can build new commits that undo its changes, and rewriting tools can replace it with a new commit, but the original is a fixed, hashed object unless Git eventually cleans up commits nothing points to.
Example
You make five commits on a plane with no internet, then push them all when you land.
Why it matters — Knowing commits are local and durable clarifies the difference between saving and sharing work.
How it works
You edit files in your working directory
You change, add, or remove files in your project folder, the working directory. Git notices these files differ from the last commit but doesn't record them yet.
Edit
Example — You fix a bug in one file and add a new one.
You stage a snapshot with git add
You run git add to place the changes you want into the staging area (the index). This marks exactly which changes will go into the next commit.
Stage (git add)
Example — You run git add on the fixed file to stage its changes.
You run git commit with a message
You run git commit and write a message. Git turns the staged snapshot into a tree and prepares a commit that points to it, to the current commit as parent, and to your details.
Commit
Example — You run git commit with a message like Fix login validation.
Git computes the commit hash
Git hashes the commit's content, the tree, parent, author, committer, and message, to produce a unique identifier for the commit (SHA-1 by default).
Hash
Example — Git generates a 40-character hash like a3f2b1c for the new commit.
Git stores the commit and moves the branch
Git saves the commit object in the repository and updates the current branch and HEAD to point to it, so the new commit becomes the latest on your branch.
Store + advance
Example — The main branch now points to your new commit as its tip.
You inspect or share the history
You review the history with git log, compare states with git diff, and, when ready, run git push to send your commits to a shared remote repository.
Inspect / push
Example — You run git log to see the new commit, then git push to share it.
Benefits
A complete, browsable history
Each commit is a full snapshot, so the history is a series of states you can return to.
You check out an old commit to see exactly how the project looked then.
Safe restore points
Commits act as checkpoints, so you can undo changes and recover a working version.
A bad change is fixed by reverting to the previous commit.
Built-in integrity
Content-based hashes make each commit tamper-evident and verifiable.
Any change to a past commit changes its hash and every hash after it.
Works offline
Committing is local, so you can save work with no network and push later.
You commit repeatedly while offline, then push when reconnected.
Foundation for branching and collaboration
Because branches and merges are built on commits, commits enable parallel teamwork.
Two developers branch from the same commit and merge their work back later.
Limitations
Only staged, tracked files are captured
MediumA commit includes what you staged with git add, not unstaged, untracked, or ignored files. Forgetting to stage leaves changes out.
Workaround — Run git status before committing to confirm what's staged.
Large binaries bloat history
MediumBecause commits snapshot content, committing large or frequently changing binaries can grow the repository quickly.
Workaround — Store large binaries with Git LFS instead of committing them directly.
Rewriting shared history is disruptive
MediumAmending or rebasing changes commit hashes. Doing this to commits others have pulled forces everyone to reconcile diverged history.
Workaround — Avoid rewriting commits that have already been pushed and shared.
A commit is only as clear as its message
LowGit records a message but can't make it useful. Vague messages leave the history hard to read later.
Workaround — Write a short, clear subject line describing what the commit does.
Committed secrets stay in history
HighObjects aren't encrypted, and a secret committed by mistake remains in the history even after you delete the file in a later commit.
Workaround — Keep secrets out of commits, and if one slips in, rotate it and scrub history with care.
Architecture
A commit sits at the center of Git's object model. It points to a tree, which points to blobs and other trees, capturing your files. It points to parent commits, forming history. Branch and HEAD references point to commits so Git knows where you are. All of these are content-addressed objects in the repository.
Working directory
Holds your actual files as you edit them, before anything is recorded.
The project folder where you write code.
Staging area (index)
Holds the snapshot you've prepared with git add, deciding what the next commit includes.
The set of changes you staged for the next commit.
Commit object
Points to a tree and parent(s) and stores author, committer, and message; named by its hash.
The object git log shows with a hash and message.
Tree and blob objects
The tree is the directory snapshot; blobs hold file contents, shared across commits.
A tree listing two files, each pointing to a blob.
Branch and HEAD refs
Movable pointers to commits; HEAD marks your current position, a branch marks its latest commit.
The main branch pointing to the newest commit.
Data flow
You edit files in the working directory, then git add stages a snapshot into the index. On git commit, Git writes the staged snapshot as tree and blob objects, creates a commit object pointing to that tree and to the current commit as parent, and hashes it. Git stores the commit and advances the current branch and HEAD to it. Later, git push copies commits to a remote repository so others can fetch them.
Integrations: git log, git show, and git diff for inspecting commits, git checkout and git switch to move between commits, Branches, tags, and merges built on commits, Remotes like GitHub and GitLab via git push and git pull, git commit --amend and git rebase to rewrite commits
Architecture limitations
Examples
The first commit in a repository
You start a new project and make your very first commit.
You create some files, stage them with git add, and run git commit. Because nothing came before it, this commit has no parent; it's a root commit. It captures the initial snapshot of your project and becomes the starting point of the whole history.
A focused feature commit
You finish one small change and want to record it cleanly.
You stage only the files for that change and commit with a clear message like Add password reset link. The commit points to the previous commit as its parent and advances your branch. Later, anyone reading the history sees exactly what changed and why.
A merge commit joining two branches
You merge a feature branch back into main.
When you merge, Git creates a merge commit with two parents, one from each branch. It ties the two lines of work together, and the history graph shows where they diverged and rejoined. If the branches changed the same lines, Git asks you to resolve the conflict first.
Comparisons
Commit vs the staging area vs The staging area (index)
The staging area is where you prepare a commit; the commit is the saved result. You add changes to the staging area with git add, then git commit records exactly what's staged as a permanent snapshot.
| Criterion | Commit vs the staging area | The staging area (index) |
|---|---|---|
| What it is | A saved, permanent snapshot | A temporary list of what to commit next |
| Persistence | Stays in history | Cleared into the commit when you commit |
| Command | git commit | git add |
When to choose — Use git add to choose what goes in, then git commit to save it as a snapshot.
Commit vs push vs git push
A commit saves a snapshot to your local repository. A push sends your commits to a shared remote. Committing is local and offline; pushing is how others see your work.
| Criterion | Commit vs push | git push |
|---|---|---|
| Where it acts | Your local repository | A remote repository |
| Needs network | No | Yes |
| Who sees it | Just you, until you push | Your team, once pushed |
When to choose — Commit to save work locally; push when you're ready to share it.
Commit vs branch vs A branch
A commit is a fixed snapshot in history. A branch is just a movable pointer to a commit, marking a line of work. Making a new commit advances the branch pointer to it.
| Criterion | Commit vs branch | A branch |
|---|---|---|
| What it is | A permanent snapshot object | A movable pointer to a commit |
| Changes over time | Fixed once created | Moves as you add commits |
When to choose — Think of commits as the fixed points and branches as labels that move along them.
Myths, corrected
Myth
A commit only stores the changes you made.
Correction
Git stores a full snapshot of your tracked files at each commit, not a diff. It stays efficient by reusing unchanged file content, and it computes diffs on demand when you ask for them. This snapshot model is a core part of how Git works.
Why it happens: Diffs are what you see in reviews and git diff, so people assume that's what's stored.
Myth
git commit saves whatever is in my folder.
Correction
A commit saves what you've staged with git add, not the whole working directory. Unstaged, untracked, and ignored files are left out. That's why a commit can miss changes you made but forgot to stage.
Why it happens: The staging step is invisible if you use commands that stage and commit together.
Myth
Committing shares my work with the team.
Correction
Committing is local. It saves to your own repository and touches no one else until you run git push. You can commit as much as you like offline, then push to share when ready.
Why it happens: In centralized tools, committing sent work to the server, so the habit carries over.
Myth
The commit hash is just a random ID.
Correction
The hash is computed from the commit's content: its tree, parent, author, committer, and message. The same content always gives the same hash, and any change gives a new one, which is why amending or rebasing changes it and why commits are tamper-evident.
Why it happens: It looks like a random string, so people assume a database assigned it.
Practical implications
For admins
Commit in small, focused units with clear messages so history stays readable and reversible. Run git status before committing to confirm what's staged.
For MSPs
For scripts, infrastructure code, and configs you version, disciplined commits give you a clean audit trail and easy rollback across client work.
For business
Good commit hygiene makes a codebase's history an asset: faster reviews, quicker debugging, and lower risk of losing or breaking work, all of which save time and money.
For security
Treat committed history as permanent. Keep secrets out of commits, since objects aren't encrypted and a committed secret stays in history even after you delete the file later.
For end users
Non-developers rarely make commits directly, but they benefit from the stable, traceable releases that clean commit history makes possible.
Cost impact
Git and committing are free and local. The main cost is the discipline to write good messages and structure commits well, which pays back in easier maintenance.
Operational impact
Commits are woven through daily development, review, and release. Consistent, focused commits speed up collaboration; messy history slows everyone down.
Decision guide
Use when
- You've reached a working, coherent checkpoint you'd want to return to
- You want to record who changed what and why
- You're about to try something risky and want a safe restore point
- You need a clean unit of change for review or collaboration
Avoid when
- You want to share work immediately; that needs git push, not just a commit
- You're bundling many unrelated changes into one commit; split them instead
- You're committing secrets or large binaries; handle those differently
- You'd be rewriting commits others have already pulled
Requirements
- A Git repository (git init or a clone)
- Changes staged with git add
- A configured user name and email for author and committer details
- A commit message
Alternatives
- The staging area to prepare changes before committing
- git stash to set changes aside without committing
- Tags to mark specific commits as releases
- Pull requests to review commits before merging
Related terms
Repository
The project's full history and object database, stored in the .git folder.
Staging area (index)
Where you prepare the snapshot for the next commit using git add.
Tree object
The snapshot of a directory that a commit points to, listing files and subdirectories.
Branch
A movable pointer to a commit, marking a line of development.
HEAD
A reference to your current commit or branch, marking where you are in history.
Merge commit
A commit with two or more parents that joins separate lines of work.
Frequently asked questions
What is a commit in Git?
A commit is a saved snapshot of your project's tracked files at a point in time. It records who made the change, when, and a message describing why, and it gets a unique hash so you can always return to that exact state.
What does a Git commit contain?
A commit records a pointer to a tree (the project snapshot), one or more parent commits, the author and committer with their names, emails, and timestamps, and your commit message. Together these describe what the project looked like and who saved it.
Does a commit store the whole project or just my changes?
A commit stores a full snapshot of your tracked files, not just the changes. Git stays efficient by reusing unchanged file content across commits, and it calculates diffs on demand when you view them.
What is a commit hash?
It's the unique identifier for a commit, a long hex string computed from the commit's content: its tree, parent, author, committer, and message. Git uses SHA-1 by default, with SHA-256 in newer versions. Any change to the content produces a different hash.
What's the difference between commit and push?
A commit saves a snapshot to your local repository, and you can do it offline. A push sends your commits to a shared remote so teammates can see them. Committing is local; pushing is how you share.
Why does the hash change when I amend or rebase a commit?
Because the hash is computed from the commit's content, and amending or rebasing changes that content, such as the message, the parent, or the committer timestamp. A different input always produces a different hash.
What is a merge commit?
A merge commit is a commit with two or more parents. It joins separate lines of work, such as merging a feature branch back into main, and records where the branches diverged and came together.
What makes a good commit?
A good commit is small and focused on one coherent change, with a clear message whose subject line says what the commit does. Focused commits with clear messages make history easy to read, review, and revert.
Conclusion
A commit in Git is a snapshot of your project's tracked files, saved permanently in the repository. It records a tree (the snapshot), one or more parent commits, the author and committer with timestamps, and a message. Git stores snapshots rather than diffs, names each commit by a hash of its content, and links commits through parent pointers into a history you can browse, revert, branch, and share.
The practical picture is simple. You edit files, stage the changes you want with git add, then run git commit to record them. That saves the work locally; you push to share it. Keep commits small and clearly described, and the history becomes a reliable, readable record of how your project came to be.
Main takeaway
Once commits make sense, the natural next steps are an explainer on Git branches and how they point to commits, and a guide to writing clear commit messages and structuring focused commits.
