Working with Remotes and GitHub

Everything so far has lived on your machine. This seventh chapter of the Git and GitHub for Beginners series adds the piece that turns a personal habit into teamwork: the remote. You will connect your repository to GitHub, push your commits, and learn the fetch/pull/push rhythm that keeps two copies of a project in step.

What a remote actually is

A remote is another copy of your repository that lives somewhere else — usually on GitHub. It has a short name (by convention origin) and a URL. Your local repository keeps its full history either way; the remote is a destination you push to and a source you fetch from. Knowing which copy you are looking at answers half of all Git confusion: local means your laptop, remote means the server, and origin/main means “what main looks like on GitHub as of my last fetch”.

Clone, fork, or fresh start

There are three ways to get a GitHub repository onto your disk, and beginners mix them up constantly:

Cloning also downloads every branch and commit, so you can browse the past immediately. Forking is a GitHub-side concept, not a Git command — it simply gives you a remote to push to when you lack write access.

Publishing your own repository

For a project you started locally, the flow is: create an empty repository on GitHub (no README, so histories do not clash), add it as a remote, then push. The -u flag on the first push is worth remembering — it sets up tracking, so later you can simply type git push and git pull without arguments. Authentication is either a HTTPS URL with a personal access token, or an SSH key (git@github.com:...) configured once and remembered forever.

Fetch versus pull

Both download new commits from the remote, but they differ in one crucial way:

• git fetch downloads only — it updates origin/main and leaves your main and your files untouched. Always safe, always worth running.
• git pull fetches and then merges (or rebases) into your current branch. Convenient, but it changes your working tree and can raise conflicts.

A reliable habit: fetch, review with git log --oneline main..origin/main, then merge when you are ready. If someone pushed while you were working, Git refuses the push and tells you to pull first — that rejection is a feature, not an insult.

Keeping every branch in view

git remote -v lists your remotes with their fetch and push URLs. git branch -a shows local branches alongside remote-tracking branches, and git push origin main publishes a branch by name. When a remote branch is deleted, git fetch --prune (or git pull --prune) tidies your stale origin/... references so the list matches reality.

git remote add origin git@github.com:sara-bakery/bakery-site.git
git push -u origin main

Expected output:

Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Writing objects: 100% (12/12), 3.42 KiB | 3.42 MiB/s, done.
To github.com:sara-bakery/bakery-site.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main' from 'main'.

git fetch origin
git log --oneline main..origin/main

Expected output:

7a8b9c0 Update the menu prices from the owner's feedback
2e3d4f5 Add opening-hours schema markup

git remote -v

Expected output:

origin	git@github.com:sara-bakery/bakery-site.git (fetch)
origin	git@github.com:sara-bakery/bakery-site.git (push)

Common mistakes

• Adding a remote to a URL that already contains a repository — the name must be short (origin), the URL goes in git remote add.
• Pushing without pulling first — a non-fast-forward push is rejected; run git pull and reconcile before trying again.
• Confusing origin/main with main — the first is what GitHub had at your last fetch, the second is your local branch.
• Skipping -u on the first push — every later push needs explicit arguments until tracking is set.
• Treating git pull as a harmless refresh — it merges into your branch and can conflict; fetch when you only want to look.

Practice checklist

1. Create an empty repository on GitHub and copy its SSH or HTTPS URL.
2. Run git remote add origin <url> in your practice repo, then confirm with git remote -v.
3. Push main with git push -u origin main and refresh GitHub to see your files.
4. Make a commit on GitHub's web editor (or a teammate's push), then git fetch and list it with git log --oneline main..origin/main.
5. Run git pull and confirm your local branch now matches the remote.

What's next?

Pushing to a shared branch is only the start of collaboration. Continue to Pull Requests and Code Review to learn how teams review work before it lands.