A commit is the basic unit of recorded work in version control. When you commit, you bundle a set of changes together and save them as a single, identified point in the project’s history. From then on you can return to that point, compare against it, or build new work on top of it.
In Git, a commit records a snapshot of the project as it stood at that moment, not just a loose pile of edits. The Pro Git book describes the act directly: you run a command such as git commit, which captures the changes you have staged and writes them into history. Crucially, “only staged changes are included in the commit,” so the act of committing is also a deliberate choice about exactly which changes belong together.
Every commit carries a message explaining the change. The book shows the common short form, git commit -m "Story 182: fix benchmarks for speed", where the quoted text is the explanation that future readers will see. A good message turns a list of altered lines into a record of intent: what was changed and why.
Because each commit is identified and ordered, commits form the backbone of everything else version control does. Branching, merging, and reviewing all operate on commits, and the history they form is what lets a team understand how a body of code reached its current state, one labeled step at a time.