Commits and the history graph

Most people learn Git as a list of commands to memorize. Instead, let's build the mental model first: once you understand what a commit is, every command becomes obvious.

A commit is a snapshot

A commit is not a list of changes. It's a complete snapshot of your project at one moment, plus a little metadata:

• a unique hash that identifies it, like a1f3c9e
• the author and date
• a message explaining why the change was made
• a pointer to its parent — the commit that came right before it

That last point is the key. Because every commit points to its parent, commits link together into a chain.

Making your first commits

Every commit goes through the same two steps: stage the changes you want, then commit them.

$ git initInitialized empty Git repository in /home/you/app/.git/$ git add README.md$ git commit -m "init"[main (root-commit) a1f3c9e] init 1 file changed, 3 insertions(+)

The staging area lets you choose exactly what goes into a snapshot, even when you've edited many files.

Reading the history graph

git log walks the chain backwards, from the newest commit to the first:

$ git log --oneline --graph* d4a8b17 (HEAD -> main) fix typo* c93e0f2 add CI* b7c2d41 add README* a1f3c9e init

Two labels matter here:

• main is a branch — just a movable name that points at a commit.
• HEAD is where you are right now. It usually points at a branch.

When you commit, Git creates the new snapshot, sets its parent to the current commit, and moves the branch forward. That's all a commit does.

In the next lesson, we'll give the graph a second branch — and see what happens when two lines of history meet.