Remote: Backing Up to a Remote | Vibe Coding with Confidence

You set up version control, so no bad change can bury the version that worked. But every commit still lives on one laptop, and a laptop can die, get lost, or land in a lake. "Never losing work" is only half true while your only copy sits on that machine. This chapter gets your code backed up somewhere off your laptop, where you can share it and later ship from it.

2.5.1Local git isn't a backup

Local git protects you from your own mistakes, not from the machine. Every commit is safe from a bad change, and every commit still lives on the same disk that can fail.

A remote is a copy of your repo hosted off your laptop, on a service like GitHub or GitLab. When you send your commits there, losing the laptop stops meaning losing the work.

A remote holds a copy of your repo off your machine, so a dead laptop loses nothing.

2.5.2Push your repo to a host

You create an empty repo on the host, then link your local one to it and send everything up. That send is a push, and after the first one, every future commit goes up with a single command.

Your agent runs this for you. The shape is worth seeing once:

git remote add origin https://github.com/you/your-app.git git push -u origin main

The first line names the remote, the second pushes your history to it. From then on, a plain git push keeps the off-machine copy current.

The remote earns its keep three ways at once:

Backup: an off-machine copy of every commit, safe when the laptop is not.
Sharing: the one place a teammate, or your other machine, pulls the latest from.
Launchpad: the source your automated tests and deploys will later pull from, when this book gets to shipping.

That third job is why this matters beyond backup. The habit you set now is the foundation the deployment part builds straight on top of.

2.5.4Keep secrets out of what you push

A remote is often public, and always shared with anyone who has access. Anything you commit and push is exposed to every one of them, so a pushed secret is a leaked secret.

This is exactly why the secrets chapter had you git-ignore your .env: an ignored file never gets committed, so it never rides a push up to the host.

Watch out: a public repo is readable by strangers and by code-scanning bots. Confirm your secrets are git-ignored before the first push, not after.

This prompt has your agent create the remote, push your code, and wire pushing into your normal flow, secrets left behind:

Ready prompt

Act as a senior engineer setting up a remote repository for my project. Do the following: - Create a new repository on my chosen host and connect my existing local repo to it. - Confirm my .env and any secret files are git-ignored, then push my full history up. - From now on, push after each set of commits so the remote copy always stays current. - Tell me the repo URL and whether it is private or public when you are done. My host and project:

Do this now: paste the prompt above so your code is backed up off your machine before you write another line.

2.5.1Local git isn't a backupAdd note

2.5.2Push your repo to a hostAdd note

2.5.3It's your backup, your sharing, and your launchpadAdd note

2.5.4Keep secrets out of what you pushAdd note

2.5.1Local git isn't a backup

2.5.2Push your repo to a host

2.5.3It's your backup, your sharing, and your launchpad

2.5.4Keep secrets out of what you push