Chapter 6.7 — Git Worktrees☕ 16 min read

Multiple Remotes — origin, upstream, heroku

Remotes = Bookmarks. Jo bhi URL save karo, waha push kar sakte ho.

01Worktree Kya Hai

A single local repository can push to MULTIPLE remote repositories. This is not a fringe feature — it is how real teams work every day.

Common remote setups:

origin — your team's GitHub repository (primary, where you push code daily)
upstream — the original open-source project (for syncing from the source)
heroku or deploy — deployment target (Heroku, Render, AWS)
staging — staging environment for testing before production
backup — a backup mirror on another server (GitLab, Bitbucket)

git remote add <name> <url> adds a new remote bookmark. Remotes are just URLs with names — you can add, rename, or remove them anytime.

# View current remotes
git remote -v
# origin  https://github.com/team/project.git (fetch)
# origin  https://github.com/team/project.git (push)

# Add upstream (for open source contributions)
git remote add upstream https://github.com/original/project.git

# Add Heroku (for deployment)
git remote add heroku https://git.heroku.com/your-app.git

# Add staging
git remote add staging https://github.com/team/project-staging.git

# Now you have 4 remotes!
git remote -v
# origin    https://github.com/team/project.git
# upstream  https://github.com/original/project.git
# heroku    https://git.heroku.com/your-app.git
# staging   https://github.com/team/project-staging.git

Remotes are bookmarks, not connections. Adding a remote does not download anything or create any network connection. It simply saves a name and URL in your .git/config. Think of it like saving a contact in your phone — the person does not know you saved their number until you call them.

02Adding a Worktree

git remote add <name> <url> — add a new remote to your repository.

git remote rename <old> <new> — rename an existing remote.

git remote remove <name> — delete a remote (does not affect the remote repo itself, only your local bookmark).

git remote set-url <name> <new-url> — change a remote's URL (e.g., switch from HTTPS to SSH).

git remote show <name> — see detailed info about a remote including tracked branches and URLs.

Naming conventions: origin is the primary remote (usually your fork or team repo), upstream is the original source, and custom names for deployment or backup remotes.

Remote names are local to YOUR repository. Your teammate might call the same URL something different. The names only exist in your .git/config.

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

# Rename a remote
git remote rename origin github  # change 'origin' to 'github'

# Change remote URL (e.g., switch from HTTPS to SSH)
git remote set-url origin git@github.com:team/project.git

# Remove a remote
git remote remove heroku
# The remote repo still exists — only the local bookmark is deleted

# See remote details
git remote show origin
# * remote origin
#   Fetch URL: https://github.com/team/project.git
#   Push  URL: https://github.com/team/project.git
#   HEAD branch: main
#   Remote branches:
#     main tracked
#     feature tracked
#   Local branches configured for 'git pull':
#     main merges with remote main

03Listing & Removing Worktrees

git push <remote> <branch> — push to a specific remote.

git push origin main — push to GitHub (code review and backup).

git push heroku main — deploy to Heroku (production deployment).

git push staging main — push to staging environment for testing.

git push --all <remote> — push all branches to a remote at once.

You can push different branches to different remotes: git push origin feature for review, git push heroku main for deployment.

git push heroku feature:main — push your local feature branch as main on Heroku. The syntax is local-branch:remote-branch.

# Push to GitHub (code review & backup)
git push origin main

# Deploy to Heroku (production)
git push heroku main

# Deploy to staging
git push staging feature:main  # push local feature as staging's main

# Push all branches to a backup
git push --all backup

# Push tags to origin
git push origin --tags

# Push a specific tag
git push origin v1.0.0

# Common workflow:
# 1. Push code to origin for review
git push origin feature
# 2. After merge, deploy to Heroku
git push heroku main

💡 Pro Tip: Heroku deployment is literally a git push. When you run git push heroku main, Heroku receives your code, builds it, and deploys it. If the build fails, the push is rejected and your existing app keeps running. This makes deployments safe and reversible.

04Worktree Use Cases

git fetch <remote> — fetch from a specific remote without merging.

git fetch --all — fetch from ALL configured remotes at once.

git fetch upstream — get changes from the original project to see what's new.

git pull upstream main — fetch and merge from upstream in one step.

Remote-tracking branches: origin/main, upstream/main, heroku/main — all live locally as read-only mirrors of each remote's state.

Compare between remotes: git diff origin/main upstream/main shows what upstream has that origin doesn't.

# Fetch from all remotes
git fetch --all

# Fetch from specific remote
git fetch upstream
# * [new branch]  main -> upstream/main

# Compare your main with upstream's main
git diff main upstream/main
# See what the original project has that you don't

# Pull from upstream
git checkout main
git pull --rebase upstream main

# See all remote-tracking branches
git branch -r
# origin/main
# origin/feature
# upstream/main
# heroku/main

# Check which remote a branch tracks
git branch -vv
# * main  abc1234 [origin/main] latest commit

05Worktree vs Stash vs Clone

Scenario 1 — Open Source: origin (your fork) + upstream (original). Push to origin, create a PR to upstream, sync from upstream regularly.

Scenario 2 — Deployment: origin (GitHub) + heroku (deploy). Push code to origin for review and backup, push main to heroku for deployment.

Scenario 3 — Enterprise: origin (internal GitLab) + upstream (open source dependency). Contribute bug fixes upstream while keeping internal changes private.

Scenario 4 — Redundancy: origin (GitHub) + backup (GitLab mirror). Push to both for backup in case one service goes down.

# Scenario: GitHub + Heroku + Upstream
git remote -v
# origin    https://github.com/your-company/app.git
# upstream  https://github.com/open-source/lib.git
# heroku    https://git.heroku.com/your-app.git

# Daily workflow:
# 1. Sync with upstream library
git fetch upstream
git merge upstream/main

# 2. Push your code
git push origin main

# 3. Deploy
git push heroku main

# Scenario: Push to multiple remotes (backup)
git remote add backup git@gitlab.com:your-company/app.git
git push backup main  # mirror to GitLab

# Set up a remote that pushes to BOTH GitHub and GitLab
# (Advanced: use git remote set-url --add --push origin backup-url)

The most common multi-remote setup is origin + upstream for open source, or origin + heroku for deployment. Understanding remotes as "bookmarks" removes the mystery. They are just named URLs. You decide which bookmark to push to or fetch from. No magic, just organization.

Lo kar liya — Key Points:

✅ A local repository can have multiple remotes: origin, upstream, heroku, staging, backup
✅ git remote add <name> <url> adds a new remote bookmark
✅ git push <remote> <branch> pushes to a specific remote
✅ git fetch --all fetches updates from all configured remotes
✅ Common setup: origin (your repo) + upstream (original source) + heroku (deployment)
✅ git remote set-url changes a remote's URL; git remote remove deletes the local bookmark
✅ Remotes are just named URLs — they don't affect the remote repositories themselves

Previous6.6 — Stash Branch & Keep Index 📋 All Chapters Next Chapter6.8 — Stash Advanced & Troubleshooting →