Git Commit: A Snapshot, Not a Diff

Why it exists

Git needs a way to record the history of a project. A commit is the fundamental unit for this history, acting as a permanent, verifiable record of the project's state at a specific point in time, allowing developers to track changes and collaborate effectively.

The mental model

A Git commit is a permanent snapshot of your entire project, not just the code that changed. Think of it as a save point in a video game. It contains the complete state of all tracked files and a pointer to the previous save point (the parent commit), forming a chain of history.

How it works

A commit is a Git object with a unique ID, which is a cryptographic hash of its contents, making it immutable. Each commit object stores several key pieces of information: first, a reference (a "tree" ID) to the project's complete directory structure and file contents at that moment; second, the ID of its parent commit(s); third, an author and timestamp; fourth, a committer and timestamp; and fifth, a descriptive commit message.

When to use it

Create a commit when you have completed a logical unit of work. This could be fixing a single bug, adding a small feature, or updating documentation. These commits become the building blocks of your project's history, used in branches, merges, and pull requests to manage development.

When not to use it

Avoid creating commits for half-finished or broken work on shared branches; use the staging area for intermediate saves. Because commits are part of the permanent record, never commit sensitive data like API keys or passwords. Once committed, it's difficult to truly erase that information from the repository's history.

One canonical example

When you fix a typo and commit, you create a new commit object with one parent: the commit you were on before the fix. A special case is a merge commit, which has two or more parents, created when you join two separate lines of history. The very first commit in a repository is also special, as it has no parents.