Managing Revision History

What You Will Learn

How to use git as a safety net when AI is writing code. When to commit, how to review AI-generated changes, how to branch for experiments, and how to revert when something goes wrong. This is not a git tutorial — it is a workflow guide for the specific challenges of AI-assisted development.

AI agents write code fast. That is both the power and the danger. Without disciplined version control, you can find yourself three hundred lines deep in changes you do not understand, with no way back to the version that worked.

The checkpoint commit is the most important habit in AI-assisted development. Before you tell Claude Code to make a change, commit what you have. If the change goes wrong, you can always get back to the last checkpoint.

# Before asking Claude to make a change:
git add .
git commit -m "checkpoint: contact form working, before adding validation"

# Now give Claude the instruction to add validation
# ...

# After reviewing the changes:
git add .
git commit -m "add client-side validation to contact form"

# See what changed (unstaged)
git diff

# See a summary of which files changed
git diff --stat

# See changes in a specific file
git diff src/components/ContactForm.jsx

You do not need to understand every line of code. But you should understand the shape of the changes. Did Claude only touch the files you expected? Did it add files you did not ask for? Did it modify something in a completely different part of the project? These are red flags.

Look for: unexpected file modifications (especially package.json, config files, or unrelated components), large amounts of deleted code, new dependencies you did not request, and hardcoded values where variables should be.

Good commit messages for AI-assisted projects:
add testimonials section to homepage
fix contact form not submitting on Safari
refactor nav to support mobile hamburger menu
checkpoint: project gallery working, before adding filters
revert: undo search feature, broke existing routing
polish: adjust spacing and typography on about page
wip: blog list renders, individual posts not yet linked

# Create a branch for the experiment
git checkout -b experiment/search-feature

# Work with Claude Code on the experiment...
# Make commits as you go...

# If it works: merge it back
git checkout main
git merge experiment/search-feature

# If it does not work: abandon it
git checkout main
git branch -D experiment/search-feature

The branch is free insurance. It takes five seconds to create and saves you from the nightmare of trying to manually undo a failed experiment across fifteen files.

# Level 1: Undo changes to a specific file (discard all uncommitted changes)
git checkout -- src/components/ContactForm.jsx

# Level 2: Undo all uncommitted changes (back to last commit)
git checkout .

# Level 3: Go back to a specific commit (the nuclear option)
git log --oneline   # find the commit hash you want to go back to
git reset --hard abc1234   # replace abc1234 with the actual hash

Level 3 destroys everything after that commit. Only use it when you are sure. This is why checkpoint commits matter — they give you a recent, safe point to reset to instead of going all the way back to the beginning.

# See recent commits (compact)
git log --oneline -20

# See what changed in a specific commit
git show abc1234

# See what changed between two commits
git diff abc1234..def5678

# Find the commit that introduced a specific file
git log --follow src/components/ContactForm.jsx

START OF SESSION
git status              (see where you left off)
git log --oneline -5    (remember what you did last time)BEFORE EACH CLAUDE CODE TASK
git add .
git commit -m "checkpoint: [what currently works]"AFTER EACH CLAUDE CODE TASK
git diff --stat          (see what files changed)
git diff                 (review the actual changes)If good:git add .
git commit -m "[what this change does]"If bad:git checkout .           (undo everything back to checkpoint)END OF SESSION
git add .
git commit -m "end of session: [summary of what got done]"
git push                 (back up to remote)

# Stage specific files only
git add src/components/ContactForm.jsx src/styles/contact.css

# See what is staged vs what is not
git status

# Commit only the staged files
git commit -m "add contact form component and styles"

# Discard the changes you did not want
git checkout -- src/pages/Home.jsx

Selective staging is a superpower. It lets you accept the changes you want and reject the ones you did not ask for, all in one step.

# Create a repo on GitHub, then:
git remote add origin https://github.com/yourusername/your-project.git
git push -u origin main

# After that, just:
git push