Cheat Sheet

GitHub for AI builders

The non-developer's guide to Git, branches, commits, and pull requests. Built for marketers and operators using AI coding tools like Claude Code.

By Ali Qureshi

The Mental Model

Think of it like Google Docs

Every Git concept maps to something you already use. Here's the translation.

Your project folder

A Google Doc

Git

The version history — every save point you can go back to

GitHub

Google Drive — where the doc lives online so it's backed up and shareable

A commit

Pressing "save" with a note about what you changed

A branch

Making a copy of the doc to try edits without messing up the original

A pull request

Asking someone to review your edits before merging them into the original

Push

Uploading your local saves to the cloud

Pull

Downloading the latest version from the cloud

Main branch

The "official" version of the doc

Core Concepts

The 7 things you actually need to know

Everything else is detail. Master these and you can work with any AI coding tool confidently.

01

Repository (Repo)

Your project folder. Everything lives here — code, files, history. One repo per project.

When you see it: When you create a new project or clone someone else's.

02

Commit

A save point. Every time you make changes and want to lock them in, you commit. Each commit has a message explaining what you changed and why.

When you see it: After you've made changes and want to save them. Claude Code will create commits for you.

feat: add landing page for lead magnet capture
03

Branch

A parallel copy of your project where you can make changes without affecting the main version. When you're done, you merge it back.

When you see it: Before starting any new feature or change. Never work directly on main.

feature/fitness-venture-assets
fix/broken-email-link

Key rule: main (or master) is the official version. Never commit directly to it.

04

Push

Upload your local commits to GitHub. Until you push, your changes only exist on your machine.

When you see it: After committing, when you want to back up to the cloud or share with others.

05

Pull

Download the latest changes from GitHub to your machine. Always pull before starting new work.

When you see it: At the start of a session, or when someone else has made changes.

06

Pull Request (PR)

A request to merge your branch into main. It shows all the changes you made and lets you (or others) review before merging. It's the quality gate.

When you see it: When your feature is done and ready to be merged into the official version.

07

Merge

Combining your branch's changes into main. After a PR is approved, you merge it. Then delete the branch — it's done its job.

When you see it: After a PR is approved. GitHub has a merge button.

The Workflow

How it works in practice

This is the typical flow when you're using Claude Code or any AI coding tool.

Step 1

Start on main

Make sure you're on the main branch and up to date.

You say:

"Make sure we're on main and pull the latest"

git checkout main && git pull
Step 2

Create a branch

Create a new branch for your work. Name it after what you're doing.

You say:

"Create a new branch for [feature name]"

git checkout -b feature/your-feature-name

Naming convention: feature/, fix/, chore/ prefixes

Step 3

Do your work

Build, edit, create — whatever the task is. All changes happen on your branch.

You say:

"Build me a landing page" / "Fix the email sequence" / etc.

Claude creates and edits files on your branch. The main branch stays untouched.

Step 4

Commit

Save your changes with a descriptive message.

You say:

"Commit this" or "Commit all of this"

git add [files] && git commit -m "feat: description"

Prefixes: feat: (new feature) fix: (bug fix) docs: (documentation) chore: (maintenance) refactor: (restructuring)

Step 5

Push

Upload your commits to GitHub.

You say:

"Push this" or "Push it up"

git push -u origin branch-name
Step 6

Create a Pull Request

Open a PR to merge your work into main.

You say:

"Create a PR for this"

gh pr create --title "feat: description" --body "summary"
Step 7

Merge and clean up

Merge the PR on GitHub, then delete the branch.

You say:

"Merge the PR" or do it on GitHub directly

Then: "Delete the branch" / "Clean up branches"

Phrase Book

What to say to Claude Code

Copy-paste these. They work.

Check current state

"What branch am I on?" / "Git status"

Start fresh

"Make sure we're on main and pull latest"

New feature branch

"Create a branch for [feature name]"

Save your work

"Commit this" / "Commit all changes"

Upload to GitHub

"Push this"

Create a review request

"Create a PR for this"

See what changed

"Show me the diff" / "What's changed?"

Go back to main

"Switch to main"

Clean up old branches

"Delete merged branches" / "Clean up branches"

Undo last change

"Revert the last commit"

See recent history

"Show me recent commits"

Check if up to date

"Am I up to date with remote?"

Naming Conventions

How to name branches

feature/

Adding something new

feature/landing-page

fix/

Fixing a bug

fix/broken-email-link

chore/

Maintenance, cleanup

chore/update-dependencies

docs/

Documentation changes

docs/add-readme

hotfix/

Urgent production fix

hotfix/payment-error

Rule: lowercase, hyphens between words, descriptive but short.

Commit Messages

How to write commit messages

The prefix tells you what kind of change it is. The message tells you why.

Format

prefix: short description of what changed

feat:

New feature

feat: add lead magnet landing page

fix:

Bug fix

fix: email form not submitting

docs:

Documentation

docs: update README with setup instructions

refactor:

Code restructure (no behavior change)

refactor: simplify email sequence logic

chore:

Maintenance

chore: clean up unused files

style:

Formatting/visual changes

style: update landing page typography

Explain the WHY, not the WHAT. "Fix bug" is bad. "Fix email form failing on mobile Safari" is good.

Mistakes to Avoid

What not to do

The mistake

Working directly on main

Instead

Always create a branch first

The mistake

Giant commits with 50 changes

Instead

One logical change per commit

The mistake

Commit messages like "update" or "fix stuff"

Instead

Be specific about what and why

The mistake

Never pushing

Instead

Push regularly. If your laptop dies, unpushed work is gone.

The mistake

Having 20 old branches

Instead

Delete branches after they're merged

The mistake

Force pushing to main

Instead

Never. Just don't.

The mistake

Committing .env files or secrets

Instead

Use .gitignore. If you see a .env file, don't commit it.

The mistake

Not pulling before starting work

Instead

Always pull main before creating a new branch

Quick Reference

The one-pager

The cycle

START checkout main pull create branch do work commit push create PR merge delete branch START

Key commands

Switch to main git checkout main
Pull latest git pull
Create branch git checkout -b feature/name
Check status git status
Stage files git add [files]
Commit git commit -m "feat: description"
Push git push -u origin branch-name
Create PR gh pr create
View diff git diff
View log git log --oneline -10
Delete branch git branch -d branch-name
Revert last commit git revert HEAD

Built for operators who build with AI

I share frameworks, tools, and systems for using AI to build real businesses. No theory — just what works.

Ali Qureshi — Founder, Adcrate