Working with Remote Repositories

By the end of this lesson you'll be able to connect a local repo to GitHub, push your commits to the cloud, pull your teammates' work, and tell fetch from pull for good — the collaboration skills every developer needs.

Learn Working with Remote Repositories in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

What You'll Learn

Real-World Analogy

A remote is the shared cloud copy of your project — think of a Google Drive folder the whole team shares. Your laptop has its own copy you edit offline. git push uploads your changes to the shared copy; git pull downloads everyone else's. GitHub, GitLab, and Bitbucket are just companies that host that shared copy for you. The nickname for your main shared copy is almost always origin — like having "Home" saved in your sat-nav so you don't retype the address every time.

1. Remotes & origin

A remote is a version of your repository that lives on a server. It is the bridge between your machine and everyone else's. The default remote — the one git clone sets up automatically — is named origin . "origin" is simply a short nickname for a long URL so you never have to retype it. You can add as many remotes as you like; a second one named upstream is common when you've forked a project. Read this worked example, run it, then you'll wire up a remote yourself.

Your turn. You've just made an empty repo on GitHub and want to link your local project to it. Fill in the two blanks marked ___ using the hints, then run it.

2. Cloning a Repository

When a project already exists on a server, you don't build the link by hand — you clone it. git clone downloads the entire history, checks out the default branch, and creates the origin remote for you in one command. This is how you start working on any existing project, whether it's yours or a team's.

3. Pushing & Tracking Branches

git push uploads your local commits to the remote. The very first time you push a new branch, add -u (short for --set-upstream ). This sets up a tracking branch — a permanent link between your local branch and its twin on the remote. After that, a bare git push and git pull automatically know where to go, so you can drop the origin branch-name part.

Now you try. You've made a new branch and want to push it for the first time with tracking, so future pushes are just git push . Fill in the two blanks:

4. fetch vs pull

This is the pair beginners mix up most. Both download new commits from the remote — the difference is what happens next. git fetch downloads the commits but leaves your files untouched, so you can inspect them first. git pull downloads and merges them into your current branch — it is literally git fetch followed by git merge . Use pull when you trust the changes; use fetch when you want to look before you leap.

Deep Dive: SSH vs HTTPS

When you connect to GitHub or GitLab, the remote URL comes in two flavours — and they only differ in how you prove who you are :

HTTPS — https://github.com/you/repo.git . The easiest to start with: you sign in with a Personal Access Token, and it works through almost any company firewall.

SSH — git@github.com:you/repo.git . You set up a key pair once, then never type credentials again. This is the usual choice once you push often.

You can switch an existing repo between them at any time — the commits don't care: git remote set-url origin git@github.com:you/repo.git .

Putting It Together: a Day of Collaboration

Here's the whole loop, using every command from this lesson — clone, branch, pull, push. A Pull Request (GitLab calls it a "Merge Request") is the request to merge your branch into the main one; it's where review and automated tests happen before your code lands.

Why pull (step 3) before you push? So your branch already includes any work teammates pushed while you were coding — that's what keeps your push from being rejected.

Pro Tips

• 💡 Pull before you push. Habitually run git pull before pushing so your branch is up to date and the push isn't rejected.
• 💡 Use git pull --rebase instead of plain git pull to keep a cleaner, straight-line history when pulling remote changes.
• 💡 Don't push straight to main . Use a feature branch and a Pull Request so your work gets reviewed before it's merged.
• 💡 git branch -vv shows which local branch tracks which remote branch — handy when a bare git push goes somewhere unexpected.

Common Errors (and the fix)

• "Updates were rejected because the remote contains work that you do not have" — someone pushed before you. Run git pull (or git pull --rebase ) to bring their commits down, resolve any conflicts, then push again. Never reach for --force on a shared branch — it deletes their work.
• "Expected new commits after git fetch but my files didn't change" — that's fetch working as designed: it updates origin/main but not your files. Run git merge origin/main (or use git pull next time) to actually integrate them.
• "fatal: repository '…' not found" / "Could not read from remote" — the remote URL is wrong or you lack access. Check it with git remote -v and fix it with git remote set-url origin <correct-url> .
• "You are in 'detached HEAD' state" — you checked out a commit or origin/main directly instead of a branch, so new commits won't belong to any branch. Get back on a branch with git checkout main , or keep your work with git switch -c new-branch .
• "src refspec main does not match any" — you tried to push before making your first commit, or the branch name is misspelled. Commit at least once, then git push -u origin main .

Quick Reference

Command

Purpose

git remote -v

List remotes and their URLs

git remote add origin <url>

Add a remote named origin

git clone <url>

Download a repo (sets up origin)

git push origin main

Upload commits to the remote

git push -u origin <branch>

First push + set tracking

git fetch origin

Download commits, don't merge

git pull origin main

Download and merge (fetch + merge)

git remote set-url origin <url>

Change a remote's URL (SSH ↔ HTTPS)

Frequently Asked Questions

Mini-Challenge: Contribute to Open Source

No blanks this time — just a brief and an outline. This is the real open-source workflow: fork, clone, add an upstream remote, branch, commit, push, and open a Pull Request. Work through it against any public repo and check your remotes with git remote -v .

🎉 Lesson Complete

• ✅ A remote is the shared cloud copy of your repo; origin is its default nickname
• ✅ git clone downloads a repo and sets up origin for you
• ✅ git push uploads commits; add -u the first time to set up a tracking branch
• ✅ git fetch downloads only; git pull = fetch + merge
• ✅ Pull before you push so your push isn't rejected; use branches + Pull Requests
• ✅ HTTPS and SSH are two ways to authenticate — switch any time with git remote set-url
• ✅ Next lesson: Resolving Merge Conflicts — the most feared Git topic, made simple

Practice quiz

Continue this course

• Previous: Branching and Merging
• Next: Resolving Merge Conflicts