# Saving your work with Git and going live

**Author:** Ivan Misic  
**Published:** 2026-01-31  
**URL:** https://ivanmisic.net/blog/ai-tools/saving-work-going-live

**TL;DR**

Keep a recoverable copy before publishing, then choose a hosting route after checking its current plan, repository support, domain setup, and build behavior.

- A dated zip stored off the computer is enough for the first restore point; open it once to prove the backup works
- Use Git when you want named history, inspectable changes, and reliable rollback
- Repository-based hosts can deploy after a push when that integration is configured; traditional hosting uses manual uploads
- Provider pricing, free-plan limits, custom-domain costs, and deployment times change, so verify them before choosing
- Inspect the exact public files, then test the deployed URL in a private browser window and click every page

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:

```text
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:

```text
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:

```text
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 GitHub
```

You 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:

1. **Repository-based hosting.** GitHub Pages, Netlify, and Vercel can publish a static site from a Git repository. Plan limits and repository requirements vary.

2. **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.

```text
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:

1. **A domain name.** Prices vary by extension, registrar, and renewal year.
2. **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:

```text
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
1. Make changes locally
2. Test in your browser
3. Commit and push to GitHub
4. Wait for the provider's deployment to finish, then test the public URL

### If using traditional hosting
1. Make changes locally
2. Test in your browser
3. 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.