Your project and its entire history are on one disk, in one laptop, in one bag.

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 like that 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

  • New repositories on github.com are public unless you change the setting, and the form asks before it creates anything. Private repositories are free, with no limit on how many. Choose private unless you have a reason to publish the code.
  • Your laptop has to prove who it is before its first push. The gentlest route is GitHub's own command-line tool: gh auth login walks through it in a browser and configures git for you. GitHub Desktop does the same thing with no terminal at all. Without one of those, a [email protected]:... address needs an SSH key on your account and will fail with Permission denied (publickey).
  • git push uploads commits. Anything uncommitted stays on your laptop, so a commit that only exists locally is protecting you from your assistant and from nothing else.
  • git clone https://github.com/you/shop.git recreates the whole project, with its full history, on another machine. That is what recovery looks like after a dead laptop, and what your host does on every deploy.
  • A is how a team reviews a change before merging. Working alone you can merge branches locally and skip the ceremony entirely.

What to do

  1. Create an empty private repository on github.com, then connect and push from the project root. Copy the https://github.com/... address from the page GitHub shows you, then: git remote add origin <url>, git branch -M main (this renames your current branch to main, which is what GitHub expects), then git push -u origin main.
  2. Read your .gitignore once more before that first push, not after. From here the history exists on someone else's servers, and in a public repository it is on strangers' machines within minutes.
  3. Connect your host to the repository instead of uploading files by hand. Vercel, Netlify, Railway, Fly.io and Cloudflare Pages all watch a branch and rebuild when it changes.
  4. Use the 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 the current code does.

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 complete GitHub history can still leave you with nothing to restore. Backups get their own pages in section 7.

Edit a file on github.com, then push from your laptop, and the push is rejected: Updates were rejected because the remote contains work that you do not have locally. Run git pull first. If the two edits touched different parts of the file, git combines them and the pull just works. If they touched the same lines, you get a merge conflict, which is routine and looks worse than it is: the file gets <<<<<<<, ======= and >>>>>>> markers around both versions, and you delete the half you do not want along with all three markers, then commit. Do not reach for git push --force here. It throws away the version you made on github.com.

The link 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.