A Git commit is a saved snapshot of your project at one specific moment, bundled with a short message describing what changed. Each commit captures the state of every file Git is tracking, gives it a unique ID, and links it to the commit before it. Strung together, commits form the timeline that lets you go back in time, compare two points, or undo a mistake. If a branch is a line of work, a commit is one fixed point along that line.
What a commit captures
A commit is not a record of a single edit; it is a full snapshot of all your tracked files as they stood when you committed. Git is efficient about storage, so unchanged files are not duplicated, but conceptually each commit represents the whole project at that instant. That is why you can check out any commit and get the entire project exactly as it was.
Each commit also carries metadata: who made it, when, a unique identifier called a hash, and a pointer to its parent commit. That parent link is what turns isolated snapshots into a connected history you can walk backward through. If you have never set up version control before, start with how to use Git and GitHub.
Staging: choosing what goes in
Git does not commit everything you changed by default. First you stage the specific changes you want with git add, then git commit saves only what is staged. This staging area is what lets you split unrelated work into separate, tidy commits.
git add login.js // stage just the login change
git commit -m "fix login redirect bug"
git add styles.css README.md // stage two more files together
git commit -m "update styles and docs"
The result is two clean commits instead of one messy one, which makes the history far easier to read months later.
Commit, branch, and tag at a glance
| Term |
What it is |
Changes over time? |
| Commit |
A fixed snapshot with a message and hash |
No, it is permanent |
| Branch |
A pointer that moves to the newest commit |
Yes |
| Tag |
A label pinned to one commit, often a release |
No |
| Staging area |
The set of changes queued for the next commit |
Yes, until you commit |
How to write commits worth keeping
- Commit small, related changes together rather than dumping a day of work into one snapshot.
- Write a clear message in the imperative mood, such as "add password reset" or "fix off-by-one error."
- Use the first line as a short summary under about fifty characters, then add detail in a body if needed.
- Commit when something works or reaches a logical checkpoint, not on a random timer.
- Avoid committing secrets, build files, or huge binaries; use a gitignore file to keep them out.
What to skip
- Skip giant catch-all commits labeled "stuff" or "wip." They make history useless when you need to find when a bug appeared.
- Skip committing broken code to a shared branch when you can. Others build on what you push.
- Skip vague messages. "fixed it" tells future readers nothing about what or why.
- Skip committing generated files. Source belongs in Git; build output usually does not.
FAQ
Is a commit the same as saving a file?
No. Saving writes to disk in your editor. A commit records a snapshot into Git history with a message, which you can return to later. You usually save many times before making one commit.
What is a commit hash?
A unique identifier Git generates for each commit, shown as a long string of letters and numbers. You can reference any commit by its hash, and you usually only need the first several characters.
Can I undo a commit?
Yes. Git offers several ways, from amending the most recent commit to reverting one with a new commit. Because history is preserved, you can almost always recover, especially if you have not rewritten shared history.
How often should I commit?
Whenever you reach a working checkpoint or finish a small, coherent change. Frequent, focused commits give you more points to roll back to and a clearer history than rare, massive ones.
Where to go next
See how a branch organizes commits, learn what a Git repository contains, and start coding from the basics.