← Back to Git Course | Chapter 4: Remote Repositories | Lesson 11 of 11

Git Remote Advanced

A project can have more than one remote, like having addresses for both your own copy and the original author's copy. That way you can send work to one and receive updates from the other.

In this page:

  1. Working with Multiple Remotes
  2. Renaming a Remote
  3. Removing a Remote
  4. Pruning Stale Remote-Tracking Branches
  5. Syncing a Fork with Upstream
Syntax
bash 
git remote add remote_name repository_url
git remote rename old_name new_name
git remote remove remote_name
git fetch remote_name

Working with Multiple Remotes

A repository isn't limited to one remote — a common pattern when working from a fork is to keep origin pointing at your own fork while adding a second remote named upstream that points at the original repository you forked from. This lets you push your own work to origin while still being able to pull the latest changes from upstream.

Example: Working with Multiple Remotes

bash 
git remote add upstream https://github.com/original/repo.git
git remote -v

Renaming a Remote

Remote names are just local aliases you can rename at any time without affecting the remote repository itself. git remote rename updates the alias everywhere Git tracks it, including the remote-tracking branches, so origin/main automatically becomes newname/main.

Example: Renaming a Remote

bash 
git remote rename origin old-origin

Removing a Remote

git remote remove deletes a remote's configuration entirely, along with all of its remote-tracking branches like origin/feature-x, but it has no effect on the actual remote repository or on your own local branches. This is useful for cleaning up a stale connection, such as an old upstream you no longer need after a project migration.

Example: Removing a Remote

bash 
git remote remove upstream

Pruning Stale Remote-Tracking Branches

When a branch is deleted on the remote, your local copy still keeps a remote-tracking branch pointing at its last known commit until you explicitly clean it up. git fetch --prune (or the shorter git fetch -p) removes remote-tracking branches for anything that no longer exists on the remote, keeping git branch -r accurate.

Example: Pruning Stale Remote-Tracking Branches

bash 
git fetch --prune

Syncing a Fork with Upstream

Keeping a fork current means fetching from upstream, merging (or rebasing) upstream's main branch into your local main, and then pushing the result to your own origin so your fork on GitHub reflects the latest history too. Skipping the final push leaves your fork's main branch behind even though your local copy is up to date.

Example: Syncing a Fork with Upstream

bash 
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
Related Topics

GitHub Remote Branch · Git remote Command · Git Remote Introduction · Git GitLab Introduction

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Naming the second remote origin too, which fails with remote origin already exists; use a different name such as upstream.
  2. Removing a remote and expecting the hosted repository to be deleted, when git remote remove only deletes your local configuration.
  3. Pushing to upstream without permission, when you normally only fetch from it and push to origin.
Chapter Summary
  • Remote repositories are hosted copies of your project, managed with git remote.
  • git fetch, git pull, and git push exchange changes with a remote.
  • GitHub, Bitbucket, and GitLab are common hosting services.
🔒

Chapter Quiz — Complete all 11 topics to unlock

0/11 topics done

Complete these topics first:

← Previous Lesson Git GitLab Introduction Next Lesson → Git reset Command

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.