Commits + history

Story

Building-a-house world — same site and crew as every Phase 0 lesson.

Every day on your build site, the foreman does one thing before knocking off: snaps a photo of everything completed that day, writes one line underneath — "poured the foundation slab, Tuesday" — and files it in the build diary.

That diary lives in the site office. You can flip back to any day and see exactly how the house looked. No page ever gets torn out. No photo ever gets replaced. Each entry has an invisible serial number printed on the back — a number so specific to that photo that if someone sneaked in and changed even one pixel, the number would be completely different. Forgery detected.

That build diary is your commit history. Each photo + note is one commit. The foreman is you (or your robot worker / AI agent) every time you run git commit.

The idea

A commit is one permanent saved snapshot of the entire project at one moment. Three things make up every commit:

• A snapshot — not just "what changed," but the full state of every file at that exact moment. You can always rewind and rebuild the project exactly as it was on any given day. [source]
• A message — a short note explaining why the change was made. (The diff already shows what changed. The message explains the why.) Future-you will thank past-you.
• A fingerprint (SHA) — a long string like a1b2c3d4e5f6, computed from the commit's full content. Change anything — even the timestamp — and the SHA changes completely. This makes history tamper-evident. [source]

Commits chain together. Each commit stores the SHA of the commit before it — its parent. That's why you can't quietly edit an old entry in the build diary: changing the old entry changes its SHA, which breaks the next entry's parent pointer, which breaks the next one, all the way to today. The chain exposes tampering automatically.

sources: docs.github.com — about-commits + about-git · fetched 2026-05-28

One-look contrast — the three parts of a commit

Real example — the syntax teaser

The git CLI is what people (and AI agents) use to create commits. GH-600 tests concepts, not every flag — but exam examples and agent logs use these constantly. Recognize the shape:

# 1. Check what changed since the last commit
git status

# 2. Stage the files you want in the next commit
git add src/checkout.js src/router.js    # specific files
git add .                                # everything changed in current folder

# 3. Seal it as a commit. -m is the message flag.
git commit -m "feat(auth): allow guest checkout when cart has items"

After step 3, a new entry appears in the build diary — one foreman snap per git commit.

An annotated real commit

Here's what a GitHub Copilot agent would produce when assigned an issue. First the command, then what gets stored in the build diary.

Step 1 — stage the changed files:

git add src/checkout.js src/router.js

Step 2 — make the commit (each -m flag adds one paragraph):

git commit \
  -m "feat(auth): allow guest checkout when cart has items" \
  -m "Skipping the login redirect when cart count > 0. Unblocks the conversion funnel for first-time buyers." \
  -m "Refs #482" \
  -m "Co-authored-by: copilot[bot] <[email protected]>"

Step 3 — what's stored (what git log and the GitHub commits page show):

commit a1b2c3d4e5f6 (HEAD -> main)
Author: You <[email protected]>
Date:   Thu May 28 16:04:21 2026 -0700

    feat(auth): allow guest checkout when cart has items

    Skipping the login redirect when cart count > 0. Unblocks
    the conversion funnel for first-time buyers.

    Refs #482
    Co-authored-by: copilot[bot] <[email protected]>

Every piece of the message maps to a literal line above:

• feat — the type. This is a new feature. Other types: fix, chore, docs, test, refactor. Tells everyone at a glance what kind of change.
• (auth) — the scope. Which area of the codebase was touched. Common scopes: auth, checkout, api, ui, db. Optional but useful in big repos.
• allow guest checkout when cart has items — the summary. Present tense, under ~72 characters. This is the bold line shown on the commits page.
• (blank line) — required separator between summary and body. Git uses the first blank line to split them.
• Body paragraph — the why. Explains motivation and context. The diff already shows what changed; the body tells future-you why you made the call.
• Refs #482 — a trailer. Links this commit to issue #482. GitHub auto-creates a backlink. Closes #482 also auto-closes the issue on merge.
• Co-authored-by: copilot[bot] <[email protected]> — agent attribution trailer. Big for GH-600. This line tells GitHub "an AI agent co-authored this commit." The commit shows up with two avatars (you + the bot). The audit log records the agent's involvement. This is one of the cert's implementation evidence patterns — proof that an agent did the work.

source: docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/about-commits · fetched 2026-05-28

git log --oneline       # one commit per line, short SHAs
git log -5              # last 5 commits, full detail
git show                # what changed in the most recent commit
git show 4427a9f        # what changed in that specific commit (use the short SHA)

Why this matters for GH-600

Every collaborator — human or AI agent — leaves a trace in commits. When an exam question shows you a commit message and asks "what does this tell you about the agent's role?" — every piece of that line has meaning. Recognize the shape and you can answer in seconds.

Check-in — three quick questions

Open-ended. Think first, then peek at the suggested answer to compare.

1. In one sentence — what is a commit, and what are its three parts?

   Suggested answer

   A commit is one permanent saved snapshot of the entire project at one moment, made up of three parts: a snapshot (the full state of every file), a message (explaining why the change was made), and a SHA (a fingerprint that makes history tamper-evident).

2. Why does the SHA matter? What would break if SHAs were just a simple counter (1, 2, 3…)?

   Suggested answer

   The SHA is computed from the commit's full content, so it changes if anything changes — even the message or timestamp. Each commit also stores its parent's SHA, so tampering with an old commit would change its SHA, breaking every later commit's parent pointer, which changes those SHAs too. The chain exposes tampering all the way forward. If SHAs were just a counter, anyone could edit history silently — you'd change commit #7 and it would still say "7." No evidence left behind.

3. The GH-600 cert tests "implementation evidence in artifacts." Where on a repo would an examiner go to prove that an agent did the work it claims it did?

   Suggested answer

   Three places together make the case: the commits tab (shows what changed and who/what authored it — look for the Co-authored-by: copilot[bot] trailer); the pull requests tab (shows the proposed changes wrapped in a review thread); and the audit log at org/enterprise level (shows system events like "agent X opened PR Y at time Z"). Commits are usually the first stop because the agent's name is right there in the attribution trailer.

Mentor marks this lesson verified in the source after you say "got it" in chat. Open-ended — no auto-grading.