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.

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.

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 .

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.

Quick Reference

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 .

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary