Two problems to solve. First: don't lose your work. Second: let other people see it.
Before publishing, keep a copy you can restore. A deleted folder, failed disk, or bad Claude edit should not send you back to the beginning.
The Simple Way: Zip Backups
Create a dated zip before a large change so you can restore the project quickly:
Create a zip file of this entire project called
my-portfolio-backup-2026-08-12.zip. Save one copy outside this
computer, such as an external drive or a cloud folder.Replace the date with today's date. Now you have a snapshot. If something goes wrong, you can extract the zip and start fresh from that point.
If you keep forgetting the backup, ask Claude to make the command repeatable:
Create a simple backup script that zips this project with today's
date in the filename. Ask me where the off-device backup should go,
then make the script easy to run again.Run the script once and confirm that the archive opens. A backup you have never tested is only a promise.
When to Back Up
Create a backup:
- Before making big design changes
- After each page is finished
- When everything looks good and you want to lock it in
- At the end of every work session
For a small site, keep a few dated versions that you know work. Delete old duplicates after the important versions also exist somewhere outside this computer.
When Git is worth it
Git records named versions of your project and shows exactly what changed between them. You can compare commits or restore an earlier version when an experiment fails.
Git and GitHub are different things:
- Git is a tool that runs on your computer. It tracks changes locally.
- GitHub is a website where you store your Git history in the cloud.
Git creates the history on your computer. GitHub stores a remote copy and can share or publish it.
Key Terms (Just Four)
| Term | What It Means |
|---|---|
| Repository | Your project folder, tracked by Git. Often called a "repo." |
| Commit | A snapshot you choose to record, with a message explaining the change. |
| Push | Upload your commits from your computer to GitHub. |
| Pull | Download commits from GitHub to your computer. |
Those four terms are enough for this workflow.
Setting It Up
If you want to use Git:
Help me set up Git for this project. Walk me through:
1. Initializing a Git repository
2. Making my first commit
3. Creating a GitHub account if I don't have one
4. Pushing my project to GitHubYou will have a local Git history and a remote copy on GitHub. Check whether the repository is public or private, review the files before the first push, and never push credentials or personal data.
Why Bother?
For a first experiment, I would start with a zip. Git becomes worth learning when you want a clear history or automatic deployment:
-
Repository-based hosting. GitHub Pages, Netlify, and Vercel can publish a static site from a Git repository. Plan limits and repository requirements vary.
-
Safer experiments. Make a commit before a redesign. If it fails, restore that version instead of guessing which zip still works.
Going Live: Putting Your Site on the Internet
For a static site, I would compare GitHub Pages, Netlify, and Vercel before paying for traditional hosting.
Repository-Based Hosting
GitHub Pages, Netlify, and Vercel can publish a static site from a Git repository. Free-plan limits, private-repository support, build times, and custom-domain features change, so check the current plan before choosing.
Help me deploy my website to Netlify using my GitHub repository.
Walk me through connecting my repo and getting a live URL.Custom Domains
If you want yourname.com instead of yourname.netlify.app, you need two things:
- A domain name. Prices vary by extension, registrar, and renewal year.
- Hosting with custom-domain support. Check the current plan before choosing.
Traditional shared hosting may bundle a domain, email, and file hosting. I would compare the renewal price and current plan before choosing it.
Which Should You Choose?
| Situation | Recommendation |
|---|---|
| Just want something live quickly | Compare GitHub Pages, Netlify, and Vercel for your repository |
| Want a custom domain, minimal fuss | Buy the domain separately and connect it to a supported host |
| Want traditional hosting with email | Shared hosting (Hostinger, etc.) |
| Already have a domain somewhere | Connect it to whichever host you prefer |
When you're ready:
Help me put my website on the internet. I want [your preference].
Walk me through the steps.Before accepting Claude's steps, check the provider's current plan and deployment documentation.
Keeping Your Site Updated
After your site is live, the update workflow depends on your setup:
If using GitHub with Netlify or Vercel
- Make changes locally
- Test in your browser
- Commit and push to GitHub
- Wait for the provider's deployment to finish, then test the public URL
If using traditional hosting
- Make changes locally
- Test in your browser
- Upload changed files via FTP or your host's file manager
I would use repository-based deployment once Git is set up. Traditional hosting avoids Git, but every update stays a manual upload.
Open the public URL in a private browser window, click every page, and confirm that no private file was published.
Next: the habits that keep Claude Code from doing damage in the first place.