One commit down. Now you add a second one, and in doing so you'll learn the single most important thing about how Git stores your project.
Each commit is a snapshot, not a diff
Most people picture Git as a series of patches: "commit 1 added these lines, commit 2 changed these lines, commit 3 deleted these lines." That mental model is wrong, and it will bite you later.
Git stores complete snapshots of your project's file tree at
each commit. When you run git log, Git isn't replaying diffs from
the beginning. It's just listing the snapshots in order. When you
run git show for a specific commit, Git computes the diff on the
fly by comparing that commit's snapshot to its parent's.
Snapshots first. Diffs derived. This is why checking out any historical commit is fast: Git just loads that commit's snapshot directly, no replay needed.
What "add a second commit" really does
You already have one commit containing README.md. Now you have a
new file notes.md in the working directory. The same two step
pattern applies:
git add notes.md
git commit -m "Add notes"
But here's the important part: the second commit's snapshot
contains both files, not just notes.md. Git snapshots the
entire tree at commit time. The fact that only notes.md is "new
in this commit" is something Git computes later by comparing to the
previous snapshot.
You can prove this to yourself:
git show HEAD --stat
Shows only notes.md in the change list. That's the diff view.
git ls-tree HEAD
Shows both README.md and notes.md. That's the snapshot view.
Linear history so far
Two commits, and the second one has the first as its parent. This is the beginning of a chain: each new commit points back to the one before it, forming your project's history. Later you'll branch off this chain, but right now it's just a straight line of two commits.
Run git log --oneline to see them both, newest on top.