App Development & Staff Augmentation Company India, USA

Managing Remotes (git remote)

git remote is the command for adding, listing, renaming, and removing the remote repositories your local repo knows about. Each remote is a short name (a label) paired with a URL. Most repos have just one (origin) — but you’re free to wire up as many as you need.

Listing remotes

Bash

git remote               # just the names
# origin

git remote -v            # names + URLs (verbose)
# origin    https://github.com/you/project.git (fetch)
# origin    https://github.com/you/project.git (push)

git remote show origin   # full details — branches, tracked state, URL
# * remote origin
#   Fetch URL: https://github.com/you/project.git
#   Push URL:  https://github.com/you/project.git
#   HEAD branch: main
#   Remote branches:
#     develop  tracked
#     main     tracked
#   Local branch configured for 'git pull':
#     main merges with remote main
#   Local ref configured for 'git push':
#     main pushes to main (up to date)

Adding a remote

Bash

git remote add <name> <url>

# Examples:
git remote add origin git@github.com:user/repo.git
git remote add upstream https://github.com/original/repo.git
git remote add staging git@deploy.example.com:project.git

Renaming a remote

Bash

git remote rename old-name new-name
# Example: rename origin to github
git remote rename origin github

Removing a remote

Bash

git remote remove old-remote
# (Alias: 'git remote rm old-remote')

# This only forgets the remote locally — the server is untouched

Changing a remote’s URL

Bash

# Switch from HTTPS to SSH (or vice versa)
git remote set-url origin git@github.com:user/repo.git

# Different URL for push (rare)
git remote set-url --push origin git@private-server:user/repo.git

Pruning stale branches

Bash

# Remove local pointers to branches deleted on the remote
git remote prune origin

# Or with fetch:
git fetch --prune

# Or set as default
git config --global fetch.prune true

Multiple remotes — when and why

Forking workflow — origin is your fork, upstream is the canonical repo. Pull from upstream, push to origin, open PRs to upstream.
Multiple deployment targets — production and staging remotes that push to different servers.
Backup remotes — push to a second host (different provider) for redundancy.
Mirrors — keep a private GitLab repo in sync with a public GitHub repo.

The fork-and-PR remote setup

A complete workflow

Bash

# 1. Fork the original repo on GitHub
# 2. Clone YOUR fork
git clone git@github.com:you/awesome-lib.git
cd awesome-lib

# 3. Add the original as 'upstream'
git remote add upstream https://github.com/original-author/awesome-lib.git

# 4. Verify
git remote -v
# origin    git@github.com:you/awesome-lib.git (fetch)
# origin    git@github.com:you/awesome-lib.git (push)
# upstream  https://github.com/original-author/awesome-lib.git (fetch)
# upstream  https://github.com/original-author/awesome-lib.git (push)

# 5. Stay synced
git fetch upstream
git switch main
git merge upstream/main
git push origin main

What URL formats are supported?

HTTPS — https://github.com/user/repo.git
SSH — git@github.com:user/repo.git
git:// — git://github.com/user/repo.git (rare, read-only)
Local path — /path/to/some/repo (works for testing or local mirrors)
ssh:// protocol — ssh://user@host:port/path/to/repo.git (when you need a non-standard SSH port)

Configuring a default push remote

If you have multiple remotes

Bash

git config branch.main.remote origin
git config branch.main.merge refs/heads/main

# Now 'git push' and 'git pull' on main go to origin

git remote affects only your machine

Changes to remotes (adding, renaming, removing) are stored in `.git/config` locally. They do not affect the server or other clones of the repo.

Tip

Stick with the convention: origin for your main remote (or your fork), upstream for the canonical repo when contributing to open source. New teammates and readers of your docs will immediately know what they mean.