App Development & Staff Augmentation Company India, USA

Introduction to Remotes

A remote is another copy of your Git repository — usually hosted on a server like GitHub, GitLab, or Bitbucket. Remotes are how Git teams share commits with each other. You push your work to a remote so others can fetch it; you pull from the remote to receive theirs.

The shape of a remote

A remote has a short name (a label like origin) and a URL (the actual location).
A repo can have multiple remotes (e.g., origin for your fork, upstream for the original).
Remotes are recorded in your local .git/config.
Remote branches are accessed as <remote>/<branch> — for example origin/main.

The default remote: origin

When you clone, Git creates 'origin' for you

Bash

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

git remote -v
# origin  https://github.com/user/repo.git (fetch)
# origin  https://github.com/user/repo.git (push)

The big picture

Local ↔ Remote

Text

Local repo                   Remote (e.g. GitHub)
─────────                    ─────────
main          ◀── push ──▶   main
develop       ◀── push ──▶   develop
feature-x     ◀── push ──▶   feature-x

origin/main      ◀── fetch ── main      (Git's snapshot of remote)
origin/develop   ◀── fetch ── develop
origin/feature-x ◀── fetch ── feature-x

Local vs remote-tracking branches

Local branches — main, feature-x. You can edit and commit to these.
Remote-tracking branches — origin/main, origin/feature-x. Read-only local pointers that remember where the remote was at the last fetch.
You never commit directly to origin/main. You commit to local main, then push to update the remote, which then updates origin/main on your next fetch.

The five commands you’ll use most

git clone <url> — copy a remote repo to your machine.
git fetch — download remote changes but don’t merge them.
git pull — fetch + merge (or rebase).
git push — upload your local commits to the remote.
git remote -v — list configured remotes.

Working with multiple remotes

Common multi-remote setup (open-source contribution)

Bash

# You forked someone else's repo
git clone git@github.com:you/their-project.git
cd their-project

# Add the original as 'upstream'
git remote add upstream https://github.com/original/their-project.git

git remote -v
# origin     git@github.com:you/their-project.git (fetch)
# origin     git@github.com:you/their-project.git (push)
# upstream   https://github.com/original/their-project.git (fetch)
# upstream   https://github.com/original/their-project.git (push)

# Keep your fork synced with upstream
git fetch upstream
git switch main
git merge upstream/main
git push origin main

Pushing for the first time

Bash

# Set up tracking on first push
git push -u origin feature-x

# Future pushes:
git push

What happens during a fetch

Git contacts the remote.
Downloads any new commits, branches, and tags.
Updates your local origin/<branch> pointers.
Does NOT touch your local branches.
You then choose how to integrate (merge, rebase, or just inspect).

Inspecting remotes

Bash

git remote -v                       # list with URLs
git remote show origin              # detailed status
git branch -r                       # remote branches
git ls-remote origin                # query remote without fetching

Remotes are local pointers

Adding or removing a remote does not touch the server. Everything happens in `.git/config` on your machine. The remote URL just says “go here when I push or fetch.”

Tip

For most projects you only ever need origin. Add a second remote (often called upstream) only when contributing to a fork.