GitHub
explained
for non-devs.

— Before you start

What GitHub
actually is.

Get the cliché *"GitHub is for devs"* out of your head. It's wrong. GitHub is a Dropbox built for code and technical documents, with three quirks that change everything:

• Full history · every change is recorded. You can roll back, compare, restore. You never lose anything.
• Collaboration · several people can work on the same files at the same time, and GitHub merges it all intelligently.
• Public or private sharing · you decide whether your folder is visible to the whole world (an open-source tool) or private to you (a personal site you're still building).

For an entrepreneur using Claude Code, GitHub has become the indispensable twin. Claude edits your files, you approve, git captures the state, GitHub stores it online. If your computer catches fire tomorrow, your work is safe. If you break something by accident, you roll back to the previous version with one command.

— The 4 concrete cases

What it does for you
day to day.

Here are the 4 situations where I, as a non-dev, open GitHub almost every day.

— Up and running in 10 min

How to set it up.

Nothing complicated · 5 steps, 10 minutes total.

1. Create a GitHub account

Go to github.com, click *"Sign up"*, pick a username (it's publicly visible, so use your real first name or your usual handle), email, password. Free account, plenty for 99% of solo use.

2. Install Git locally

Git is the software that talks to GitHub from your computer. On a Mac it's often already there · test with:

git --version

If it answers with a number, you're set. Otherwise, xcode-select --install and you'll get Git as a bonus (on Mac). On Windows, download git-scm.com.

3. Set up your identity

In your terminal, tell Git who you are (it'll show on every commit):

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

4. Create your first repo

On GitHub, click the green *"New"* button top right, give your repo a name (say my-site), choose *"Private"* (you can flip it to public later), click *"Create repository"*. GitHub shows you the commands to connect your local folder.

5. Push your first content

In your local folder, type:

git init
git add .
git commit -m "First commit"
git remote add origin https://github.com/YOUR_USERNAME/my-site.git
git branch -M main
git push -u origin main

It's long the first time. After that, it's just git add . → git commit -m "message" → git push. 3 commands, automatic within 2 days.

— The toolkit

The 5 commands
worth actually knowing.

Git has 150+ commands. You only need 5. The rest, Claude knows for you.

Command	What it does	When
git status	Tell me what's changed since my last commit	Before committing, to check you know what you're saving
git add .	Stage all the changes for the next commit	Right before commit, once you're happy
git commit -m "…"	Capture the current state with a message explaining it	At every milestone (end of a feature, end of a session)
git push	Send my commits up to GitHub	When you want to save online or trigger a Vercel deploy
git pull	Grab the changes someone else (or you on another machine) pushed	At the start of a session, if you work on 2 machines or with someone

A typical day's cycle: git status (I look) → changes via Claude → git add . → git commit -m "what I did" → git push. 4 commands, 20 seconds, your work is saved online.

Bonus · git clone and git checkout

git clone URL · downloads a repo from GitHub to your computer. You use it to grab an open-source tool or copy a sample project.

git checkout -b new-branch · creates a "branch" so you can test a big change without touching the stable version. Handy when you want to experiment without fear. Claude handles this for you if you ask.

— The classic traps

The 3 mistakes not to make.

Trap 1 · Pushing an API key by accident

One day, you put a Resend API key in a .env file, you run git add . without looking, you push. Your key is now public on GitHub, bots find it within minutes, and your usage explodes.

The absolute rule · create a .gitignore file at the root of your project with at least:

.env
.env.local
.env.*
node_modules/
.DS_Store

These files will never get sent to GitHub. Ask Claude *"make me a standard .gitignore for my project"*, and it generates the right version.

Trap 2 · The git push --force that wipes everything

If someone else (a dev, an agent) pushed changes you haven't pulled, and you run git push --force, you overwrite their work with no way back. Git will warn you · never force without understanding why. The right move is almost always git pull first.

Trap 3 · Mixing up public and private repos

A public repo is visible to everyone on the internet · perfect for an open-source tool. A private repo is for you only (and the people you invite) · mandatory for a site you're still building, client data, or a confidential prototype.

GitHub always asks at creation. Default to private. You can always switch to public later; the other way around is messier.

— The combo that changes everything

GitHub + Claude Code,
the magic workflow.

Here's what my typical day looks like with the two combined.

1. Morning · I run claude in my site's folder. Claude reads my CLAUDE.md and knows everything about the project.
2. I ask for a change · "add a section on the tools page for Remotion." Claude edits the files.
3. I check it visually via dev-browser or a local browser.
4. If it's good, I tell Claude · "commit and push." It writes the message, runs git add . && git commit -m "…" && git push.
5. Vercel redeploys the site automatically in 45 seconds.
6. If something breaks · "undo my last commit." Claude runs git revert, pushes, and the site is back to the previous version. Zero stress.

This whole workflow takes me 10 to 30 seconds once the change is made. That's why GitHub is inseparable from Claude Code for me · even without writing a line of code, I run my site like a seasoned dev, with the safety net that comes with it.

— Going further

Your next steps.

1. Claude Code · the full setup · install it first if you haven't yet
2. Vercel · hosting and deployment · GitHub's natural partner for your site
3. The glossary · CLI / Terminal · if the terminal still scares you
4. GitHub Docs · docs.github.com/en · the official docs, well written
5. GitHub Skills · skills.github.com · free interactive tutorials to learn the basics

If you have a specific question about GitHub or a particular use case for a non-dev entrepreneur, reply to my newsletter. It lands in my inbox, I read everything, I reply. Real-world feedback beats generic articles a thousand times over · including the one you just read.