Saving your work with GitHub

You’ve built something. Now let’s make sure it can never be lost — not if your laptop dies, not if a change goes wrong. This is what Git and GitHub are for, and the good news is your assistant does the fiddly parts. Your job is to understand what’s happening and to give the right instructions.

Two words, one idea: never lose work

Think of a video game:

• A commit A saved snapshot of your whole project at one moment, with a short note describing it. Like a labeled save point. is a save point. It captures your whole project at this moment, with a short note like “added the hobbies section.” You can always return to a save point.
• Git A tool that creates and manages your save points (commits) on your own computer. is the tool that makes those save points, right on your computer.
• GitHub A free website that stores a copy of your project and all its save points online, as a backup and a way to share. is the cloud: it keeps a copy of your project and every save point online, so it survives anything happening to your laptop.
• A repository Your project's home on GitHub — the online box holding all its files and save points. (everyone says “repo”) is just your project’s labeled box on GitHub.

So the full loop is: make save points (commit) on your computer, then upload them (push) to your box (repo) on GitHub.

Connect your computer to GitHub (one time)

Before your computer can upload to GitHub, the two need to be introduced. This only happens once. The easiest way: ask your assistant to handle it. With Claude Code running in your project, say:

Help me connect this computer to my GitHub account so I can
back up my work. Walk me through any sign-in steps.

It will set things up and tell you if you need to approve something in your browser. Follow its lead — when it asks you to sign in to GitHub or authorize a connection, do it, then come back to the terminal.

Save and back up your work

Once connected, backing up is a single plain-English request. Try:

Save my work with a commit, then create a private GitHub repo
called "about-me" and push it there.

Behind the scenes it will: make a save point (commit) with a sensible note, create your online box (repo) on GitHub, and upload (push) everything to it. It’ll show you a link to your new repo when it’s done. Open that link — seeing your own files sitting safely on GitHub is a real milestone.

⤢ click to enlarge

Your README: the project’s front page

Open your repo on GitHub and you’ll notice something: below the list of files, GitHub shows a nicely formatted write-up about the project. That comes from a single special file in your project called a README A plain-text file (README.md) that GitHub automatically displays as your project's front page. The place to explain what the project is and how to use it. — its full name is README.md. GitHub treats it as the project’s front page: it’s the first thing anyone (including future-you) sees, and it’s effectively the description of what the project is.

The .md ending means it’s written in Markdown A simple way of formatting plain text — a # makes a heading, a dash makes a bullet — that GitHub turns into a tidy page. You don't need to learn it; Claude writes it. , a simple text format that GitHub turns into a clean page with headings and bullets. You don’t have to learn it — this is exactly the kind of thing to hand to your assistant. Just ask:

Write a README.md for this project. Explain in plain language what
it is, what it does, and how to run it. Keep it friendly and short.
Then commit and push it so it shows up on GitHub.

Refresh your repo page and there it is — your project with a real front page. This is the same documentation habit from Module 8: a README is a place your project remembers what it is, so neither you nor a fresh Claude conversation has to start from scratch. A good rhythm is to ask Claude to “update the README” whenever the project grows.

One rule worth burning in: no secrets in your repo

Here’s the thing to understand before you ever push: everything in your project folder gets uploaded with it. That makes a repo the wrong place for anything private — and you should treat this as a permanent habit even in a private repo, because repos often become public later:

• Never put passwords, keys, card numbers, or personal details (home address, phone number, full date of birth) into your project’s files.
• Programs that need a secret keep it in a special .env file A plain-text file (named .env) that holds secret settings like keys and passwords. It's deliberately kept out of your repo so secrets never get uploaded. , which is deliberately kept out of the repo so it never gets uploaded.

The easy way to stay safe is to let your assistant handle it. Before your first push, you can ask — and notice this is a great thing to fold into your prompts:

Before we push, check this project for anything sensitive like
passwords, keys, or personal info. Set up a .gitignore so files
like .env are never uploaded to GitHub.

The save habit

From now on, whenever you finish a chunk of work you’re happy with, back it up. You don’t need to remember any commands — just tell your assistant:

Commit my changes with a clear message and push to GitHub.

A good rhythm is to do this every time you finish something that works — a new section, a fixed problem, a look you like. Each push is a moment you can safely return to.

What just happened, in one breath

You connected your computer to GitHub, made a save point of your project, created an online box for it, and uploaded it. Your work now lives in two places. That’s the entire point of this module — and you mostly did it by asking.

Next: actually running your project so you can see it work in a browser.