The Core Safety Loop: Your "Save Game" for AI Coding

You just prompted the AI to refactor a module, and it went silent for a moment. What exactly did it touch? Before you do anything, you need situational awareness.

git status is your "heads-up display." The output shows three categories:

On branch feature/login
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/auth.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   src/routes.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/session_store.py

The good news? You don't actually need to type git status in the terminal. VS Code shows you all of this visually. Just click the Source Control icon in the Activity Bar (the branch icon on the left sidebar). The badge shows how many files changed, and each file is labeled M (modified), U (untracked), or D (deleted):

VS Code Expand

You can also spot changes right in the editor without opening the Source Control panel. VS Code adds colored indicators in the gutter (the narrow strip to the left of your code): green for added lines, blue for modified lines, and a red triangle for deleted lines. Click any indicator to preview the change inline:

VS Code Expand

Now you know what changed. The next step is the most important one: reviewing the AI's work line by line, and only approving what you trust. This is staging — your quality gate.

Step Zero: Actually Read the Diff

git status tells you which files changed; git diff shows you what changed inside them — removed lines in red with a -, added lines in green with a +. It's the terminal twin of the VS Code Diff Editor you'll meet below, and it's the command every AI agent runs before staging (Part 6 makes it a rule).

git diff            # Unstaged changes: working directory vs staging area
git diff --staged   # Staged changes: what the next commit will contain

Option 1: Stage All (the "trusting" add)

git add .

Option 2: Stage One File (the "surgical" add)

git add src/my_file.py

Option 3: Stage Parts of a File (the "AI-first developer's" add)

Here's how to start an interactive staging session:

git add --patch  # or git add -p

For each hunk, Git asks: y (stage), n (skip), s (split into smaller pieces), q (quit). In the Try It: The Complete Loop playground (next section), git add -p is simplified to file-by-file staging — type y or n on the next line for each file.

The VS Code Way: Visual Staging

This is where VS Code really shines. Instead of typing cryptic y/n/s/q responses in the terminal, you get a beautiful side-by-side Diff Editor. To stage an entire file, just hover over it and click the + button:

VS Code Expand

When you click a file in the Changes list, VS Code opens the Diff Editor -- a side-by-side view showing the old version (left) and new version (right). This makes it easy to review exactly what changed before staging:

VS Code Expand

For even more precision, click a file to open the Diff Editor, then select specific lines and right-click → "Stage Selected Ranges". This is the visual equivalent of git add -p, but far easier to use:

VS Code Expand

You've reviewed the changes and staged the ones you trust. Now it's time to freeze this moment in time — a commit is your permanent save point that you can always travel back to.

git commit -m "feat: add user authentication endpoint"

The command itself is simple, but the message you write matters more than you might think.

Where the "Why" Actually Goes: the Body

The subject line above says what changed. The "why" lives in the commit body — a blank line after the subject, then as many lines of context as the change deserves. Run git commit with no -m and Git opens your editor (VS Code, if you set core.editor in Part 1) for exactly this:

fix(auth): reject expired tokens before the DB lookup

The AI's first fix checked expiry after loading the user, which
let expired tokens trigger a full query. Checking first avoids
the load and matches how the session middleware already behaves.

Save and close the editor tab, and the commit completes. (Changed your mind? Close it with an empty message and Git aborts the commit.)

One last habit: prove to yourself the save point exists. Right after committing, run git log --oneline -1 — one line, your hash and message. (That's also the final step Part 6 teaches agents: commit, then report the hash.)

In VS Code, committing is just as simple: type your message in the input box at the top of the Source Control panel and click the Commit button (or press Cmd+Enter / Ctrl+Enter). Notice the sparkle icon next to the input -- click it to let AI generate a commit message from your staged changes:

VS Code Expand

Here's the AI commit message feature in action. After staging your changes, click the sparkle icon and Copilot will analyze your diff and write a descriptive message for you:

VS Code Expand

Try It: The Complete Loop

You asked the AI to scaffold your project, and it delivered: dependencies installed, an .env file holding your API keys, and a working app. Then it helpfully runs git add . — and now your secrets, your node_modules folder, and a stray .DS_Store are all staged for your next commit. You just learned how permanent a commit is — before you freeze that mistake into history, you need to teach Git what to ignore.

A .gitignore file is a plain text file at the root of your repository that lists patterns of files Git should pretend don't exist. Ignored files never show up as "untracked" in git status, and git add . silently skips them. The file itself gets committed, so the whole team — and every AI agent working in the repo — shares the same guardrail.

# Dependencies
node_modules/
.venv/
__pycache__/
*.pyc

# Secrets & local config
.env
.env.*
!.env.example

# Build output
dist/
build/
coverage/

# Logs & caches
*.log
.cache/

# AI tool local state (personal settings stay personal)
.claude/settings.local.json
CLAUDE.local.md
.cursor/
.aider*

(Purely personal noise like .DS_Store or .idea/ belongs in your global ignore file instead — see the end of this section. And while a repo's main .gitignore lives at the root, you can drop extra ones in any subfolder to scope rules to just that corner of the project.)

Pattern Syntax Essentials

• *.log — a glob: matches any file ending in .log, in any directory
• dist/ — a trailing slash matches only directories (and everything inside them)
• /config.json — a leading slash anchors the pattern to the repository root
• docs/**/*.tmp — ** matches any depth of nested directories
• !.env.example — a leading ! negates a pattern, re-including a file an earlier rule excluded (it can't re-include anything inside an excluded directory, though)

The Gotcha: Already-Tracked Files Stay Tracked

.gitignore only affects untracked files. If a file was already committed before you added it to .gitignore, Git keeps tracking it — and keeps committing your changes to it. To stop tracking a file without deleting it from your disk, remove it from the staging area (which Git's own messages call the index — same thing, older name):

git rm --cached .env
# For a whole directory:
git rm -r --cached node_modules

# Then commit the removal
git commit -m "chore: stop tracking ignored files"

A Global Ignore File for OS and Editor Junk

Files like .DS_Store (macOS) or Thumbs.db (Windows) are about your machine, not the project. Instead of asking every repository to ignore them, configure a global ignore file that applies to all your repositories:

git config --global core.excludesFile ~/.gitignore_global

echo ".DS_Store" >> ~/.gitignore_global
echo "Thumbs.db" >> ~/.gitignore_global

Line Endings: the Cross-Platform Papercut

Windows ends lines with CRLF, macOS and Linux with LF. On a mixed team this produces the classic horror diff: every line of the file "changed" because a teammate's editor rewrote the endings — and AI agents reformatting files make it worse. The team-level fix is a committed .gitattributes file, which overrides everyone's personal settings:

# Commit LF, let Git normalize what each OS checks out
* text=auto

# Files that must keep exact bytes, no conversion ever
*.png binary
*.webp binary

(You may also see core.autocrlf in older guides — that's the per-machine version of the same idea. Prefer .gitattributes: it lives in the repo, so it protects teammates and agents who never configured anything. If a diff ever claims every line changed, check line endings before anything else.)