Skip to content

3.3 Git: Your Safety Net

Here's the deal that makes agent work safer to explore: before an agent touches your project, save a checkpoint of the tracked files. If you approve what it did, keep it. If not, Git can restore those tracked files. Git does not cover everything, but knowing its boundary makes it a dependable first layer.

What you will learn

  • Explain what Git does in one sentence and why agents make it non-negotiable.
  • Run the core cycle: init, status, add, commit.
  • Restore unwanted changes to tracked files without discarding work casually.
  • Push a project to GitHub as backup and portfolio.

Builder principle

Commit before the agent works, commit after you approve. Checkpoints make experiments cheaper and easier to inspect.

What Git is

Git saves named checkpoints of tracked project files and lets you compare or restore those files later.

Each snapshot is a commit — the full state of your project plus a message saying what changed. The history of commits is your project's story, told in receipts.

The boundary matters:

  • Tracked files are in Git's history. git restore can recover their committed content.
  • Untracked files are visible to git status but are not in a commit yet.
  • Ignored files such as .env are intentionally outside Git.
  • External state — a database row, sent email, deployed service, or deleted cloud resource — is outside the repository.

Git can restore the first category. Backups, previews, service-specific undo, and permission gates protect the others.

The core cycle

Do this along with the lesson, inside the project from 3.2:

Turn on tracking (once per project):

$ cd ~/builds/quick-win
$ git init
Initialized empty Git repository in /Users/jordan/builds/quick-win/.git/

Check what's changed (any time, constantly):

$ git status

git status is read-only and the single most-typed Git command on earth. It shows which files are new or modified since the last snapshot.

Review, stage, and snapshot:

$ git status --short
$ git diff
$ git add README.md notes/brief.txt
$ git commit -m "Starting point: README and notes"

Stage the paths you reviewed rather than staging the whole working tree automatically. This reduces the chance of committing an unrelated file or secret. commit -m records that reviewed set with a message.

See the story so far:

$ git log --oneline
a1b2c3d Starting point: README and notes

The rollback — why you're really here

Simulate an agent making a mess:

$ echo "TERRIBLE IDEA" > README.md
$ cat README.md
TERRIBLE IDEA

Set-Content -Path .\README.md -Value "TERRIBLE IDEA"
Get-Content .\README.md
TERRIBLE IDEA

Now undo it:

$ git restore README.md
$ cat README.md
# Quick Win

git restore .\README.md
Get-Content .\README.md
# Quick Win

The tracked file is back to the last commit. Before restoring real work, inspect git diff and name the exact paths: restoration discards uncommitted changes in those tracked files.

Agent-created files need a separate check:

$ git status --short
$ git clean -nd

git clean -nd is a preview only: it lists untracked files Git would remove. Review that list and remove only files you are certain are disposable. Do not turn the preview into a blanket deletion when you are unsure, and remember that ignored files and external systems still need their own recovery plan.

This checkpoint rhythm is the heartbeat of every lab from Chapter 4 forward:

COMMIT  →  let the agent work  →  inspect tracked + untracked changes
        →  COMMIT reviewed paths (or restore selected tracked paths)

That's enough for now: init, status, diff, path-specific add, commit, and selected restore. Branches, merges, and pull requests come later. Let Claude Code suggest Git commands, but read the status and the exact paths yourself before approving anything that discards work.

You know Git — so here's the agent-era spin: commit granularity becomes your review granularity. Small, frequent commits around agent turns give you diffable checkpoints of machine work (git diff HEAD~1 = "show me exactly what the agent did"). In Chapter 10, worktrees turn this into parallel agent lanes. Start treating your Git history as an audit log of delegation, not just a change log.

GitHub: an optional remote copy

A remote repository keeps another copy of pushed commits. It can be private or public, and it still depends on your account, repository availability, and which commits you actually pushed. Public repositories may support a portfolio; never publish secrets or private data.

$ git branch -M main

Create a repository on github.com named quick-win (no README — you have one), then connect and push:

$ git remote add origin https://github.com/YOURNAME/quick-win.git
$ git push -u origin main

Refresh the GitHub page: the commits you pushed are now in that remote repository. Confirm its visibility setting. A private repository is the default choice for practice that is not intentionally public.

Watch

Git and GitHub for Beginners — Crash Course — freeCodeCamp. The first half hour reinforces everything above with visuals; the rest is there when you're ready for branches.

Try it now

The full safety-net drill, unassisted:

  1. In quick-win, run git status — clean?
  2. Add a line to notes/brief.txt, run git status again — see the change tracked?
  3. Review with git diff, then run git add notes/brief.txt and git commit -m "Add brief line" as two separate commands.
  4. Vandalize a tracked practice file, inspect its diff, rescue that file with git restore notes/brief.txt, and confirm again.
  5. Create a disposable untracked file, then use git status --short and git clean -nd to see how Git classifies it. Remove it manually only after confirming its name.
  6. If you configured an authorized remote, push and inspect its commit history. Record whether the repository is private or public.

Check your understanding

  • What is a commit, and what two things does it contain?
  • What's the checkpoint rhythm, and which state remains outside Git?
  • A tracked file got mangled since your last commit. What do you inspect before restoring it, and what exact command restores only that file?
  • Why will neither git restore nor a commit undo a sent email or recover an ignored local database?
  • What does GitHub add that local Git doesn't? Name both benefits.