Everything from the previous three sections lives on one disk, in one laptop, in one bag. Git gives you a full history of the project and keeps all of it in the same place as the project.

GitHub is the second place. It is also, less obviously, the way your code reaches the internet at all.

The idea

GitHub stores a copy of your repository on its servers and puts a website in front of it. You send commits up with git push and pull them down with git pull. That copy is your backup, your browsable history, and the source almost every hosting platform reads from when it builds and deploys your site. A stored copy on GitHub is called a , and yours will be named origin.

text
   YOUR LAPTOP                        GITHUB                    THE INTERNET

   working tree                    origin/main
        |  commit                       |                     +-------------+
        v                               |     on each push    |  Vercel /   |
   local history  --- git push ---->  copy of  ------------->  |  Railway /  |
                  <--- git pull ---   history                  |  Fly.io     |
                                        |                     +-------------+
                                        |  browsable:                |
                                        |  every commit, every diff  v
                                        |  every file, any date   your live site

How it works

  • git remote add origin [email protected]:you/shop.git tells your local repository where its copy lives. You do this once.
  • git push uploads commits you have made. Anything uncommitted stays on your laptop and is not backed up by pushing.
  • git clone [email protected]:you/shop.git recreates the whole project, with its full history, on another machine. This is what recovery looks like after a dead laptop, and also what your host does on every deploy.
  • Repositories are private by default when you choose so, and private repositories are free on the personal plan. Choose private unless you have a reason to publish the code.
  • A is how a team reviews a change before it merges. Working alone, you can merge branches locally and skip the ceremony. The part worth keeping is the Files changed view, which is a good place to read your own diff before it goes live.

What to do

  1. Create an empty private repository on github.com, then connect and push in the project root: git remote add origin <url>, git branch -M main, git push -u origin main.
  2. Push at the end of every working session. A commit that only exists locally is protecting you from your assistant and from nothing else.
  3. Connect your host to the repository rather than uploading files by hand. Vercel, Netlify, Railway, Fly.io and Cloudflare Pages all watch a branch and rebuild when it changes.
  4. Use the commit history as a record. Clicking any commit on github.com shows its diff and its date, which answers "when did this break" faster than reading current code.

Where it breaks

Pushing code is not backing up a product. Your database, your uploaded files and your production secrets are not in the repository and never should be, so a full GitHub history can still leave you with nothing to restore. Backups get their own section in Chapter 6.

The connection between GitHub and your host also means a push can become a deploy in under a minute, which is convenient right up to the first time it is not. Once real users exist, that automatic path is worth putting a branch in front of.

One more caution: anything you push is on GitHub's servers and, in a public repository, on other people's machines within minutes. Deleting the file later does not remove it from history. Check .gitignore before the first push, not after.