Git Workflow

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 in a shopping cart before checkout.

git add index.html style.css README.md

Or, to stage everything:

git add .

The . means “everything in the current directory.”

Step 3: Commit (git commit)

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

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"

The git status command (step 2) shows you what’s changed since your last commit. It’s your “what happened?” command — use it frequently.

A real example

Let’s say you used Claude Code to build a contact form:

# Start with a clean commit
git status                    # Nothing to commit, working tree clean

# Run Claude Code, it creates/edits files
claude
> "Add a contact form to the homepage with name, email, and message fields"

# Check what Claude changed
git status
# modified:   index.html
# new file:   contact.js

# Stage and commit
git add .
git commit -m "Add contact form with client-side validation"

Now if Claude’s next task breaks something, you can always go back:

git checkout .                # Undo all changes since last commit

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.