Introduction to Remotes

A remote repository is a version of your project hosted somewhere other than your local machine — typically on a platform like GitHub, GitLab, or Bitbucket, or on a private server. Remotes are what make collaboration possible. They give your team a shared point of reference: a place where everyone can push their work and pull others' work from.

Understanding remotes is the bridge between using Git locally and using it as a collaboration tool.

What "Remote" Actually Means

The word "remote" does not necessarily mean the repository is far away on the internet. A remote is simply a repository that is somewhere other than your current working directory — it could be on another path on the same machine. What matters is that all the standard operations — pushing, pulling, fetching — work the same way regardless of where the remote physically lives.

A repository can have multiple remotes. Each remote is given a shortname — a human-readable alias for its URL — so you can refer to it conveniently in commands without typing the full address every time.

origin — The Default Remote

When you clone a repository, Git automatically creates one remote called origin pointing back to the URL you cloned from. This is just a convention — origin has no special meaning in Git beyond being the default name assigned at clone time. You can rename it or add others freely.

git clone https://github.com/user/project
cd project
git remote
# origin

Listing Remotes — git remote

To see all configured remotes for the current repository:

git remote

To see the URLs associated with each remote:

git remote -v

origin  https://github.com/user/project (fetch)
origin  https://github.com/user/project (push)

Each remote shows two URLs — one for fetching (downloading) and one for pushing (uploading). In most cases they are the same, but they can differ.

A repository with multiple remotes — common when working with several collaborators or forks — might look like this:

origin      git@github.com:wariz/campus-access (fetch)
origin      git@github.com:wariz/campus-access (push)
upstream    https://github.com/original/campus-access (fetch)
upstream    https://github.com/original/campus-access (push)

Adding a Remote — git remote add

To add a new remote to an existing repository:

git remote add <shortname> <url>

Example:

git remote add upstream https://github.com/original/project

Now you can refer to that repository as upstream in all subsequent commands instead of typing the full URL.

Fetching from a Remote — git fetch

git fetch downloads all new data from a remote that you don't have locally — new commits, new branches, updated references — but it does not automatically merge anything into your working branches:

git fetch origin

After fetching, the remote's branches are available locally as remote-tracking branches (covered in full in the next topic). You can inspect them, compare them, and merge them manually when you are ready.

git fetch origin                    # Fetch from origin
git fetch upstream                  # Fetch from a different remote
git fetch --all                     # Fetch from all configured remotes

git fetch vs. git pull

This distinction is important:

git fetch is the safer, more deliberate choice — it lets you inspect what came in before deciding how to integrate it. git pull is more convenient but less explicit. Many experienced developers prefer git fetch + manual merge for important branches.

Pulling from a Remote — git pull

git pull fetches and merges in one step:

git pull origin main

If your current branch is set up to track a remote branch, you can omit the remote and branch names:

git pull

Git will fetch from and merge into the tracked upstream branch automatically.

From Git 2.27 onwards, Git warns if pull.rebase is not configured. Set your preference explicitly to suppress the warning:

# Merge on pull (default behaviour)
git config --global pull.rebase false

# Rebase on pull (cleaner history)
git config --global pull.rebase true

Pushing to a Remote — git push

To share your local commits with a remote:

git push <remote> <branch>

Example:

git push origin main

This uploads your local main branch to the origin remote. The push only works if:

1. You have write access to the remote.
2. Nobody else has pushed to that branch since you last fetched. If they have, your push will be rejected and you must fetch and integrate their work first before pushing again.

git push origin main              # Push main to origin
git push origin feature-login     # Push a feature branch
git push -u origin feature-login  # Push and set up tracking

The -u flag (short for --set-upstream) tells Git to remember the relationship between your local branch and the remote branch, so future git push and git pull commands on that branch can omit the remote and branch name.

Inspecting a Remote — git remote show

For a detailed look at a specific remote — its URL, which branches it tracks, and what push/pull behaviour is configured:

git remote show origin

* remote origin
  Fetch URL: https://github.com/user/project
  Push  URL: https://github.com/user/project
  HEAD branch: main
  Remote branches:
    main           tracked
    feature-login  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)

This tells you which remote branches are tracked, what will happen when you run git pull, and whether your local branch is up to date with the remote.

Renaming a Remote — git remote rename

git remote rename origin upstream

This renames the remote shortname from origin to upstream and updates all remote-tracking branch references accordingly. What was origin/main becomes upstream/main.

Removing a Remote — git remote remove

git remote remove upstream

This removes the remote reference entirely. All associated remote-tracking branches and configuration settings are deleted. The actual remote repository is unaffected — only your local reference to it is removed.

A Complete Remote Workflow

Here is what a typical collaborative workflow looks like using remotes:

# Clone the project — sets up 'origin' automatically
git clone https://github.com/team/project
cd project

# Make changes on a feature branch
git switch -c feature/dark-mode
# ... do work ...
git add .
git commit -m "Add dark mode toggle"

# Push the branch to the remote and set up tracking
git push -u origin feature/dark-mode

# Fetch any updates from the team in the meantime
git fetch origin

# Merge the latest main into your feature branch
git merge origin/main

# Push your updated branch
git push

Summary