Connecting to GitHub

Course 1 · Ch 5

Remotes, push/pull/clone, and choosing between SSH keys and personal access tokens

Everything so far has happened entirely on your own machine. This chapter connects that local repository to GitHub — turning it from a private history only you can see into something backed up, shareable, and ready for the collaboration features covered throughout the rest of this series.

What a "Remote" Actually Is

A remote is simply a saved URL pointing to a copy of your repository hosted somewhere else — almost always GitHub for this series, but it could be GitLab, Bitbucket, or even another folder on your own machine. Your local repository and the remote are two independent copies of the same history; git's job is keeping them in sync via push and pull.

💻

Local Repository

Your machine — everything from Chapters 1–4 happens here

git push → ← git pull

☁️

Remote (GitHub)

A hosted copy — the shared source of truth for collaboration

"origin" is just a nickname, not a special keyword

By convention, the main remote is named origin — but that's purely a naming convention, not a git requirement. You could name it github, upstream, or anything else. Almost every tutorial and tool assumes origin, so it's worth sticking with unless you have a specific reason not to (Course 2, Chapter 4 covers fork workflows where a second remote, conventionally upstream, becomes genuinely useful).

Two Ways to Start — New Repo vs Existing Repo

Option A: You already have a local project (from Chapters 1–4)

$ # 1. Create an empty repository on github.com first (no README, no .gitignore — keep it empty)
$ # 2. Link your local repo to it
$ git remote add origin https://github.com/yourname/my-project.git
$ # 3. Push your existing history up
$ git push -u origin master

Option B: Starting from a repository that already exists on GitHub

$ git clone https://github.com/yourname/my-project.git
Cloning into 'my-project'...
remote: Enumerating objects: 12, done.
Receiving objects: 100% (12/12), done.

git clone downloads the full history and automatically sets up origin for you — no git init or git remote add needed. This is by far the most common way most people start working on an existing project.

Authenticating with GitHub — SSH vs Personal Access Tokens

GitHub no longer accepts your account password for git operations over HTTPS — you need either an SSH key pair or a personal access token (PAT). Both work; they suit slightly different situations.

🔑

SSH Keys

A key pair generated once on your machine. The private key stays on your computer, never shared; the public key is uploaded to your GitHub account. Once set up, authentication is automatic — no typing credentials, ever.

Best for: your own personal machine, used long-term. Slightly more setup effort upfront, but the smoothest experience afterward.

🎫

Personal Access Tokens

A long random string that acts like a password, generated from GitHub's settings, used over HTTPS. Can be scoped to specific permissions and given an expiry date.

Best for: temporary or shared machines, CI/CD pipelines, or quick one-off setups where generating an SSH key feels like overkill.

Setting up SSH (the recommended approach for your own machine)

Generate a key pair

ssh-keygen -t ed25519 -C "you@example.com" — accept the default file location, set a passphrase if you want extra protection.

Copy the public key

The public key is the file ending in .pub (e.g. id_ed25519.pub) — never copy or share the file without .pub, that's your private key.

Add it to GitHub

Settings → SSH and GPG keys → New SSH key. Paste the public key content in.

Use the SSH URL, not HTTPS, when cloning

git clone git@github.com:yourname/my-project.git — GitHub shows both URL formats on every repository page; pick the SSH one.

Already using HTTPS and tired of typing your token every time?

Run git config --global credential.helper store (or manager on Windows, often set up automatically) to cache your token after the first use, instead of switching to SSH. Both authentication methods are completely valid long-term choices — this is about convenience, not correctness.

Pushing and Pulling

$ # Send your local commits up to GitHub
$ git push

$ # Bring down commits made elsewhere (another machine, a collaborator)
$ git pull

git push works only if your local branch is at or ahead of the remote's version — if someone else has pushed commits you don't have locally yet, git will reject the push and ask you to pull first. This exact scenario — and what to do about it — is the subject of Chapter 10's two-person collaboration scenario.

Never commit secrets, even to a private repository

API keys, passwords, and .env files pushed to GitHub remain in history forever, even if you delete them in a later commit — anyone with repo access (or anyone who later finds a leaked private repo) can dig them out of old commits. Chapter 6 covers .gitignore, which prevents this category of mistake from happening in the first place.

Command Reference

Command	What it does
git remote add origin <url>	Link an existing local repo to a GitHub repository
git remote -v	Show the URL(s) your remotes point to
git clone <url>	Download a full copy of a remote repo, with origin already set up
git push	Send local commits to the remote
git push -u origin master	Push and remember this remote/branch as the default for future pushes
git pull	Fetch and merge remote commits into your local branch

Chapter 5 Quick Reference

A remote is just a saved URL to another copy of your repository — usually GitHub
origin is the conventional name for your main remote, not a special keyword
git clone sets up origin automatically; git remote add is for connecting an existing local repo
SSH keys — best for your own long-term machine, no repeated credential prompts once set up
Personal access tokens — best for temporary/shared machines and CI pipelines, scoped and expirable
git push / git pull — send and receive commits; push fails if the remote has commits you don't have yet
Never commit secrets — they persist in history even after deletion in a later commit
Next chapter: .gitignore — exactly what should never be tracked, and how to enforce it automatically