Saving Your Work | LLM CLI Training

Putting it all together

You’ve learned git basics in Module 7. Now let’s put it together into a complete workflow that you’ll use every time you work on a project.

The complete save workflow

1. Before you start working

Always start by checking the state of things:

git status                    # Any uncommitted changes?
git log --oneline -5          # What were my last few commits?

If you have uncommitted changes from a previous session, commit them first:

git add .
git commit -m "Save work in progress from last session"

2. While you’re working

Commit at natural breakpoints — not every tiny change, but at meaningful moments:

After the AI finishes a feature: commit
Before asking the AI to do something risky: commit
After fixing a bug: commit
When you stop for a break: commit

git add .
git commit -m "Add search functionality to product page"

3. Before you stop for the day

Always push to GitHub before closing your laptop:

git add .
git commit -m "End of day: polish mobile layout"
git push

This ensures your work is backed up. If your laptop dies, your code is safe on GitHub.

The git workflow cheat sheet

# Morning routine
cd my-project
git status
git pull                      # Get any changes from GitHub

# Work session (repeat as needed)
# ... use AI tools, make changes ...
git status                    # See what changed
git add .                     # Stage everything
git commit -m "Description"   # Save with a message

# End of day
git push                      # Back up to GitHub

Writing good commit messages

Your commit messages are a record of your project’s history. Future you will thank present you for clear messages.

Good messages describe the WHAT and WHY:

git commit -m "Add user login page with email/password form"
git commit -m "Fix cart total not updating on quantity change"
git commit -m "Improve mobile layout for product grid"
git commit -m "Remove unused dependency (lodash)"

Bad messages that help nobody:

git commit -m "updates"
git commit -m "fix"
git commit -m "wip"
git commit -m "asdf"

The format

Start with a verb: Add, Fix, Update, Remove, Refactor, Improve, Create

[Verb] [what changed] [optional: why or where]

Examples:

Add dark mode toggle to navigation
Fix broken image links on about page
Update pricing to reflect new plans
Remove deprecated API endpoint

💡Commit messages are for humans

You’re writing these for yourself (or teammates) to understand later. When you look at git log in 3 months, you should be able to understand what each commit did without reading the code.

Setting up a new project for GitHub

If you’re starting a new project from scratch, here’s the full setup:

# Create and enter project folder
mkdir my-awesome-project
cd my-awesome-project

# Initialize git
git init

# Create a .gitignore file
echo "node_modules/
.env
dist/
.DS_Store" > .gitignore

# Do your initial work (scaffold with AI, create files, etc.)
# ...

# Make your first commit
git add .
git commit -m "Initial project setup"

# Create a GitHub repo (using GitHub CLI)
gh repo create my-awesome-project --public --source=. --remote=origin --push

# Or manually:
# 1. Create repo on github.com
# 2. git remote add origin https://github.com/YOU/my-awesome-project.git
# 3. git push -u origin main

The .gitignore essentials

Every project needs a .gitignore. Here’s a solid starting template:

# Dependencies
node_modules/

# Build output
dist/
build/
.output/

# Environment variables (secrets!)
.env
.env.local

# OS files
.DS_Store
Thumbs.db

# Editor files
.vscode/
.idea/

# Logs
*.log

⚠Never commit secrets

If you accidentally commit a .env file with API keys, the keys are in your git history forever (even if you delete the file later). If this happens, revoke the keys immediately and generate new ones. Prevention is better: always have .env in your .gitignore before creating the file.

What to commit, what to skip

Commit	Don’t commit
Source code (`.js`, `.html`, `.css`, `.jsx`, `.ts`)	`node_modules/`
Configuration files (`package.json`, config files)	`.env` and secrets
README and documentation	Build output (`dist/`, `build/`)
`.gitignore`	OS-specific files (`.DS_Store`)
Test files	Large binary files (videos, huge images)

The rule of thumb: commit things you created or configured. Don’t commit things that can be generated or downloaded.