Setup

Git Init First

Before you write a single line of code — before you even open your AI agent — you need git. If you already have it, skip to initializing your repo.

Installing Git

Mac: Git ships with Xcode Command Line Tools. Open a terminal and run:

xcode-select --install

If that tells you it’s already installed, you’re good.

Windows: Download the installer from git-scm.com. Use the default settings. This gives you Git Bash — a terminal that speaks the same language as Mac and Linux tutorials, including this guide.

Linux: Use your package manager:

# Debian / Ubuntu
sudo apt install git

# Fedora
sudo dnf install git

# Arch
sudo pacman -S git

Verify it worked:

git --version

Tell Git Who You Are

Git tags every commit with your name and email. Set these once:

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

If you use GitHub, use the email associated with your GitHub account. This links your commits to your profile.

Initialize Your Repo

Now the part that matters. Before you open your AI agent, initialize a git repository:

git init
git add .
git commit -m "initial commit"

This is non-negotiable. Git is your undo button. Without it, every mistake your agent makes is permanent. With it, every mistake is a git diff away from being understood and a git checkout away from being undone.

Commit Early, Commit Often

Every time your agent does something that works — commit it. Don’t wait until the feature is done. Don’t batch changes. Small, frequent commits give you fine-grained undo points.

A good rhythm:

1. Ask your agent to do something
2. Review what it did
3. If it looks good, commit
4. If it doesn’t, revert
5. Repeat

Branches Are Parallel Universes

A branch is a copy of your code that you can mess with without affecting the original. The main branch is your source of truth — the version that works. Everything else is an experiment.

# Create a branch and switch to it
git checkout -b add-login-page

# Now you're on the new branch.
# Everything you commit here stays here
# until you merge it back.

Use branches for every feature, fix, or experiment your agent works on. If it goes well, merge it. If it goes sideways, delete the branch. Main stays clean either way.

A few naming conventions that keep things readable:

git checkout -b feature/user-auth
git checkout -b fix/login-redirect
git checkout -b refactor/api-client

The prefix tells you what kind of work it is. The rest tells you what it touches. When you have twenty branches (and you will), this saves you from playing detective.

Merging

When your branch is ready, merge it back into main:

# Switch back to main
git checkout main

# Merge your branch in
git merge add-login-page

# Delete the branch — it's done its job
git branch -d add-login-page

Sometimes git can’t figure out how to combine changes from two branches. This is a merge conflict. Git will mark the conflicting sections in the file:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> add-login-page

You pick which version to keep (or combine them), remove the markers, and commit. Your editor probably has a tool for this — use it. Resolving conflicts by hand in a raw text file is a rite of passage, not a best practice.

Pull Requests

A pull request (PR) is a merge that asks for permission first. Instead of merging directly, you push your branch to GitHub and open a PR. This gives you (and anyone else) a chance to review the changes before they hit main.

# Push your branch to GitHub
git push -u origin add-login-page

Then open a PR on GitHub. The PR shows every change, every file, every line. This is where code review happens. Even if you’re working solo, PRs give you a moment to pause and look at the full picture before merging.

If you’re using GitHub’s CLI (and you should be — it’s called gh), you can do the whole thing from the terminal:

# Push and create a PR in one flow
git push -u origin add-login-page
gh pr create --title "Add login page" --body "Basic login form with email/password"

The Undo Toolkit

Things go wrong. Here’s how to undo them:

git checkout -- path/to/file.js

git reset --soft HEAD~1

git reset --hard HEAD~1

The git diff Ritual

git diff is the most important command in vibe coding. It shows you exactly what changed, line by line — every addition, every deletion, every file your agent touched.

git diff

You’ll see something like this:

diff --git a/src/auth.ts b/src/auth.ts
index 3a1b2c4..9d8e7f6 100644
--- a/src/auth.ts
+++ b/src/auth.ts
@@ -12,7 +12,9 @@ export async function login(email: string, password: string) {

-  const user = db.query("SELECT * FROM users WHERE email = " + email);
+  const user = await db.query(
+    "SELECT * FROM users WHERE email = $1",
+    [email]
+  );

Lines starting with - were removed. Lines starting with + were added. In this case, your agent just fixed a SQL injection vulnerability — exactly the kind of thing you want to catch before it ships.

Run it after every agent interaction. Before every commit. Make it muscle memory. Agent generates code → git diff → review → commit or revert. Every single time.

This is your vibe check in its purest form. A 30-second scan of the diff catches problems that would take hours to debug in production. If something looks wrong or confusing, don’t commit — ask your agent to explain what it did and why.