Git and GitHub from zero

If you learn one thing properly from Part 1, make it this. Version control is what turns "I broke my app and I don't know what changed" into "no problem, back to yesterday". Working with AI agents that edit dozens of files at a time, it isn't optional — it's the seatbelt.

The idea, stripped of jargon

Git is a program on your computer that takes snapshots of your project. GitHub is a website that stores copies of those snapshots online. They're separate things that go together, and people muddle them constantly.

Every snapshot — a commit — records exactly what every file looked like at that moment, plus a note from you saying why. You can return to any of them, at any time, forever. Think of it as an unlimited, permanent undo that also works across many files at once.

The vocabulary

Getting set up

1. Make a GitHub account at github.com. Free. Use a username you wouldn't mind a future investor seeing.
2. Install Git. On a Mac, typing git --version in the terminal will offer to install it. On Windows, get it from git-scm.com.
3. Tell Git who you are — this stamps your name on every commit:

   git config --global user.name "Your Name"
   git config --global user.email "[email protected]"

4. Install GitHub Desktop from desktop.github.com. It's a free app that does the everyday Git operations with buttons instead of commands, and shows you diffs beautifully. Not a beginner's crutch — plenty of engineers use it for exactly this.

The loop you'll repeat forever

Roughly ten times an evening:

1. Decide on one small thing to change.
2. Make the change (or have the AI make it).
3. Check it works in the browser. Actually click it.
4. Commit, with a message describing what you did.
5. Push to GitHub.

In commands, if you want them:

git status                      # what's changed?
git add .                       # stage everything
git commit -m "Add pricing section to homepage"
git push                        # send it to GitHub

Writing commit messages

Finish the sentence "This commit will…". So: Add email validation to signup form. Not update, fix, stuff, or asdf. In three weeks you'll be scrolling this list looking for the moment something broke, and your past self's laziness will be very annoying.

The two commands that save you

Learn these before you need them, because you'll need them at the worst possible moment.

Throw away everything since the last commit

git restore .

The AI went rogue, files are a mess, nothing works. This wipes all uncommitted changes and returns you to your last commit. It is permanent — anything not committed is gone. That's the point.

Go back to a specific earlier commit

You want the version from two hours ago. Find it in GitHub Desktop's history, or ask the AI: "Show me my last 10 commits and help me get back to the one where the signup form was working." This is normal, everyday Git use, not an emergency procedure.

Branches, and how much to care

A branch is a parallel copy where you can try something risky. If it works, merge it. If it doesn't, delete it and main never knew.

Honestly: while you're solo and pre-launch, committing straight to main often and pushing is fine. Branches earn their keep in two situations, and both will arrive:

• You have real users and main is the thing they're using. Now experiments must happen elsewhere.
• You're trying something big and speculative — a redesign, swapping a library. A branch means you can abandon it entirely with one command.

git checkout -b redesign-homepage   # create and switch to a branch
# ...work, commit...
git checkout main                   # back to the safe version

Private or public — and why yours must be private

Every repository on GitHub is one or the other, and the choice is made when you create it. It's the most consequential setting on the whole site, and it takes two seconds to get wrong.

Make every business repository private. There's no cost saving in going public and no benefit you need at this stage. GitHub's free plan has given unlimited private repositories for years — the "private costs money" belief is simply out of date.

What a public repo actually exposes

• Secrets, within minutes. Automated bots continuously scan every new public commit for API keys. This isn't a theoretical risk — it's the single most common way small companies get an unexpected cloud bill or a data breach.
• A map of your application. Your database schema, your API routes, your permission rules, which checks happen on the server and which don't. Obscurity isn't a security strategy, but handing an attacker the blueprint makes their job dramatically easier — especially if your row level security isn't airtight.
• Real customer data you didn't mean to commit. Seed files, a CSV export used for testing, a database dump saved "just for a minute", screenshots in your README with real names in them. This is more common than leaked keys, and worse.
• Your commercial thinking. Commit messages and issues read as a roadmap: what you're building, what you abandoned, what's broken, how your pricing works.

Things people believe that aren't true

Sensible defaults

• Create it private, always. Choose the visibility on the creation screen rather than fixing it later.
• Turn on push protection in your repository's security settings. GitHub will then block a push that contains something that looks like a credential — a safety net for the mistake you'll eventually make at 11pm.
• Audit what you already have. Old practice repos and tutorial projects are frequently public and frequently contain a real key from the day you were experimenting.
• Watch your gists too. A "secret" gist is unlisted, not private. Pasting code into a public gist, a forum or a Discord is the same exposure as a public repo.
• Give contractors the least access that works, and remove them when the work ends.

What the GitHub website gives you

Beyond backup, three things you'll actually use:

• A full history you can browse from any device — every change, when, and why.
• Issues — a built-in to-do list attached to your project. Genuinely good for tracking bugs and ideas, and free.
• Connection to hosting. Services like Vercel and Netlify watch your repo and redeploy your live site automatically every time you push. This is how deployment becomes a non-event; see Getting it online.

I'm a non-technical founder who has just started using Git and GitHub. I understand that commits are snapshots, but I don't have an intuition for it yet.

Teach me by walking me through the 7 situations I'm most likely to hit in my first month — things like: I broke everything and want to go back; I committed something I shouldn't have; I'm on the wrong branch; my push was rejected; I have changes I forgot about from two days ago.

For each one:
- What it looks like from my side (the exact error or symptom I'd see)
- What's actually going on underneath
- The safe fix, step by step
- What NOT to do in a panic

Then give me a printable one-page cheat sheet of just the commands from those fixes.

Check this repository's Git setup as if you were a security-conscious senior engineer reviewing a beginner's first project.

1. Show me what's in .gitignore and tell me whether anything important is missing.
2. Check whether any secrets, API keys, credentials or .env files are currently tracked by Git, or appear anywhere in the commit history.
3. Check whether node_modules or other large generated folders are being committed.
4. Look at my last 10 commit messages and tell me honestly whether they'd be useful to me in three months. Rewrite three of them as examples of better ones.
5. Tell me whether this repo is set up so that I could safely delete my entire computer and lose nothing.

If you find a leaked secret, tell me the exact steps to deal with it — including that I need to revoke the key, not just delete the file.

I want to become confident that I can never lose work. Design a 30-minute hands-on drill for me, using a throwaway test repository, that makes me practise recovering from disaster.

Include drills for:
- Undoing all uncommitted changes
- Going back to a specific commit from earlier today
- Recovering a file I deleted by accident
- Undoing a commit I already pushed to GitHub
- Getting my whole project back onto a fresh computer from GitHub alone

For each: give me the exact steps to cause the problem deliberately, then the exact steps to recover, then how to verify I really recovered. I want to have made and fixed each disaster myself before it happens for real.

Act as a security-minded engineer reviewing my GitHub presence before I take on paying customers.

1. Tell me how to list every repository and gist I own and see which are public — including old practice and tutorial projects I've forgotten about.
2. For this repository: is it public or private, and how can I verify that myself rather than taking your word for it?
3. If any repo of mine were public, walk me through exactly what a stranger could learn from it: files, full commit history, commit messages, issues, and anything in older commits that isn't in the current files.
4. Search this repository's entire history for credentials, real customer data, database dumps, CSV exports, or anything else that shouldn't be published.
5. Tell me how to turn on secret scanning and push protection, and what each one actually blocks.

For anything you find, tell me the order to deal with it in — and be explicit that revoking a leaked key comes before deleting the file.

Read this project the way an attacker would if the repository were public, and write me a short report.

Tell me:
1. What the application does, and what the most valuable data in it is
2. My database structure, and which tables hold personal information
3. Every API route, and for each one whether permission is enforced on the server or only hidden in the UI
4. Which checks I'm relying on the browser to perform — i.e. which ones a user could simply skip
5. The three things in here that would most help someone trying to get at data they shouldn't have
6. Anything in the commit history that isn't in the current code but would still be readable

I'm non-technical, so explain what each finding would actually let someone do. Then tell me which of these I should fix regardless of whether the repo is private — because private isn't a security control.