How to manage multiple remotes in Git
Łukasz Holeczek
Follow Łukasz Holeczek on GitHub
Connect with Łukasz Holeczek on LinkedIn
Follow Łukasz Holeczek on X (Twitter)
Managing multiple Git remotes lets you push code to different destinations simultaneously — maintaining mirrors on GitHub and GitLab, working with both origin and upstream in open-source projects, and deploying to different environments from the same repository.
As the creator of CoreUI with 25 years of open-source development experience, I maintain multiple remotes in every major project: the canonical repository, contributor forks, and deployment targets.
The commands are simple — git remote add, git remote set-url, and git push --all — but understanding when to use each pattern makes a significant difference in team workflows.
You can have as many remotes as needed; there is no Git limit.
Add and manage multiple remotes.
# View current remotes
git remote -v
# Add a second remote (e.g., GitLab mirror)
git remote add gitlab https://gitlab.com/org/repo.git
# Push to a specific remote
git push gitlab main
# Push to all remotes at once
git push --all origin
git push --all gitlab
Each remote has a name and URL. The default remote is called origin by convention. Add more with git remote add <name> <url>. Push to any remote explicitly by name.
Push to Multiple Remotes Simultaneously
Configure a combined push remote.
# Method 1: Use a push URL alongside fetch URL
git remote set-url --add --push origin https://github.com/org/repo.git
git remote set-url --add --push origin https://gitlab.com/org/repo.git
# Now 'git push origin main' pushes to both GitHub and GitLab
git push origin main
# Verify the configuration
git remote -v
# origin https://github.com/org/repo.git (fetch)
# origin https://github.com/org/repo.git (push)
# origin https://gitlab.com/org/repo.git (push)
--add --push adds an additional push URL without changing the fetch URL. git push origin now pushes to all configured push URLs sequentially. This is useful for maintaining mirrors without changing your daily workflow.
Fork Workflow with Origin and Upstream
The standard open-source contribution pattern.
# Fork on GitHub, then clone your fork
git clone https://github.com/your-username/repo.git
cd repo
# Add the original as upstream
git remote add upstream https://github.com/original-owner/repo.git
# Fetch upstream changes and merge into your fork
git fetch upstream
git merge upstream/main
# Push to your fork
git push origin main
origin is your fork. upstream is the original repository. This is the same pattern used by all CoreUI contributors. See how to sync fork in Git for the full fork synchronization workflow.
Deployment Remotes
Push to a deployment remote to trigger builds.
# Add a Heroku deployment remote
heroku git:remote -a my-app-name
# This adds a 'heroku' remote automatically
# Or add manually for any platform
git remote add production ssh://user@deploy-server/~/repo.git
git remote add staging ssh://user@staging-server/~/repo.git
# Deploy to production
git push production main
# Deploy to staging from a feature branch
git push staging feature/new-ui:main
feature/new-ui:main pushes your local feature/new-ui branch to the remote’s main branch — useful when the deployment platform expects main.
Best Practice Note
In CoreUI projects we maintain origin (GitHub), a GitLab mirror for redundancy, and deployment remotes for staging and production. Always verify your remote configuration with git remote -v before pushing to avoid pushing to the wrong destination. Use descriptive remote names (staging, production) rather than generic ones to prevent accidental pushes to production when you intend to push to staging.
