Git Workflow

By the end of this lesson, you’ll be able to create a git repository, stage your changes, and commit them — the three-step workflow you’ll repeat every time you work on a project.

The Mental Model: Packing a Shipment

Think of saving your work in git like packing a box to ship:

1. Your desk is the working directory — files are spread out, some changed, some new.
2. The packing table is the staging area — you pick which items go in this particular box.
3. Sealing and labeling the box is the commit — you write what’s inside and it’s saved.

You don’t have to pack everything at once. You choose what goes in each box, label it clearly, and stack the sealed boxes on a shelf where you can always open any of them later.

The Three-Step Workflow

Using git day-to-day requires just three steps:

1. Make changes to your files (or let the AI do it)
2. Stage the changes you want to save (git add)
3. Commit them with a message (git commit)

That’s it. Let’s walk through each one.

Step 0: Create a Repository

Before git can track a project, you need to initialize it:

mkdir my-project
cd my-project
git init

git init creates a hidden .git folder inside your project. This is where git stores all the version history. You never need to touch this folder — git manages it automatically.

Step 1: Make Changes

Create some files (or let your AI tool create them):

touch index.html
touch style.css
echo "# My Project" > README.md

At this point, git knows these files exist but hasn’t saved them yet. They’re “untracked.”

Step 2: Stage Changes (git add)

Staging tells git which changes you want to include in your next commit. Think of it as putting items on the packing table before sealing the box.

git add index.html style.css README.md

Or, to stage everything:

git add .

The . means “everything in the current directory” (except files listed in your .gitignore).

Step 3: Commit (git commit)

A commit is the actual save point. Every commit has a message describing what changed:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

git commit -m "Add initial project files"

The -m flag lets you write the message inline. The message should be short and describe what you did.

Good commit messages:

• "Add login page with form validation"
• "Fix broken link in navigation"
• "Update styles for mobile responsiveness"

Bad commit messages:

• "stuff" — too vague
• "asdfgh" — meaningless
• "I made some changes" — no useful information

The Complete Flow

Here’s the pattern you’ll repeat hundreds of times:

# 1. Make changes (or let AI make them)
# ... edit files, run AI tools, etc.

# 2. Check what changed
git status

# 3. Stage the changes
git add .

# 4. Commit with a descriptive message
git commit -m "Add contact form with validation"

# 5. (Optional) Verify your commit was saved
git log --oneline

The git status command (step 2) shows you what’s changed since your last commit. It’s your “what happened?” command — use it frequently. You can also run git status at any time between steps to check where things stand. The git log --oneline at the end shows your commit history in a compact list, confirming your work was saved.

Worked Example: The Commit-Before-AI Pattern

This is the most important git habit you’ll build. Every time you’re about to ask an AI tool to make changes, commit first. Here’s a complete walkthrough:

# You've been working on a project — commit what you have
git add .
git commit -m "Working homepage with header and hero section"

# Now ask Claude Code to add a new feature
claude
> "Add a contact form to the homepage with name, email, and message fields"

# Claude edits index.html, creates contact.js, modifies style.css
# Check what changed
git status
# modified:   index.html
# modified:   style.css
# new file:   contact.js

# It looks good — save this progress
git add .
git commit -m "Add contact form with client-side validation"

Now suppose you ask Claude for another change and it breaks things:

# Ask Claude for something ambitious
> "Redesign the entire page layout to use a sidebar navigation"

# Check the result... the page is broken
# No problem — revert to the last working commit
git restore .

That one command — git restore . — throws away all uncommitted changes in tracked files and restores them to the last commit. Your contact form is back, working perfectly. This is why you always commit before asking the AI to make big changes.

The Staging Area Visual

Think of it like preparing a package to ship:

Working Directory    →    Staging Area    →    Repository
(your files)              (git add)            (git commit)

 index.html  ─────────→  index.html  ──────→  Commit #1
 style.css   ─────────→  style.css   ──────→  "Add initial files"
 app.js      (not added)

Files in the working directory that aren’t staged won’t be included in the commit. This gives you control over exactly what gets saved.

Key Takeaways

• Three commands are all you need: git add . to stage, git commit -m "message" to save, git status to check.
• Always commit before asking the AI to make changes. This is your most important safety habit.
• git init starts tracking a folder. You only need to do this once per project.
• Staging gives you control. You choose exactly which changes go into each commit.
• If AI changes break something, revert. git restore . throws away all uncommitted changes to tracked files and takes you back to your last save point.