One commit is a save. Several commits are a history — a line of points you can walk back along.
git log — read the history
git log
0a1b2c3 (HEAD -> main) first commit
Each entry has:
- a hash like
0a1b2c3— the commit’s unique name - a message — what you wrote with
-m - on a real , also the author and the date
HEAD marks where you are standing right now, and main is the name of the branch you are on.
Note
This simulator prints one stand-in log line rather than your actual commits. On a real repository, git log lists every commit newest-first, and git log --oneline compresses each to a single line — which is how most people read it day to day.
Quick check
What is the hash in a git log entry for?
Why history is the point
A commit is not a backup of one file. It is a snapshot of the whole project at one moment. Returning to a commit restores every tracked file together, in a state that once worked.
That changes what is risky. Consider two versions of the same afternoon:
Without commits. You ask an agent to restructure the project. It edits fourteen files. Something breaks in a way you do not understand. Your options are to debug a change you did not write, or to start over.
With a commit first. Same afternoon, same breakage — except there is a known-good snapshot from ten minutes ago. You go back and try a smaller request.
The agent is equally capable in both stories. The difference is entirely whether you left yourself a way back.
Tip
The rule that costs nothing: git status should say “working tree clean” before you hand an agent a big task. If it does not, commit first. It takes ten seconds and it is the only reason you can be relaxed about the next twenty minutes.
Quick check
Before asking an agent to make a large refactor, what is the ten-second precaution?
Small commits, often
A commit costs nothing. Ten small ones are far more useful than one enormous one, because each is a place you can return to.
Compare:
add user login
against:
add user login, fix the header, update the readme, rename some variables
If the login work turns out to be wrong, the first history lets you undo exactly that. The second forces you to choose between keeping all four changes or losing all four.
Quick check
Why are small, frequent commits better than one large one?
Try it
Two commits, so you can see a history form:
git initgit add .git commit -m "add the homepage"git log— one entry.touch about.html— a new page.git status— one untracked file, and the rest is clean.git add about.html— stage only the new page.git commit -m "add the about page"git log
Look at step 6 carefully. Git is telling you precisely what has changed since the last snapshot — nothing more, nothing less. That is the report you want in front of you after an agent has been working.
Where this goes next
You now have the whole ground floor: moving around, reading and writing files, searching, pipes, and version control. That is the environment every runs in, and enough of it to read what one is doing over your shoulder.
The next course installs a real agent and points it at a real project.