Advanced Remotes

Managing a single origin is easy, but DevOps engineers often handle multiple remotes—especially when working with forks or maintaining mirrors of a repository.

1. Managing Remote Connections

You can manipulate your remote links using the git remote command suite:

Check Current Remotes: View the URLs linked to your local repo.
```
git remote -v
```
Change a Remote's URL: Common when a repo moves from HTTPS to SSH or to a new domain.
```
git remote set-url origin git@github.com:user/new-repo.git
```
Rename a Remote: Useful if you want to change origin to something more descriptive.
```
git remote rename origin primary
```
Remove a Remote: Clean up links to repos you no longer need.
```
git remote remove old-server
```

2. Origin vs. Upstream

In a standard open-source workflow (forking), you will likely have two primary remotes:

Name	Role	Usage
`origin`	Your Fork.	Where you push your feature branches.
`upstream`	The Original Repo.	Where you fetch the latest official changes to stay in sync.

# Typical setup for a contributor
git remote add upstream https://github.com/original-org/project.git

3. Resolving Remote Issues

Permission Denied: Check if you're using the correct SSH key or if your PAT has expired.
Remote Repo Not Found: Verify the URL is correct and you have access to the repository on GitHub/GitLab.

[!TIP] Use SSH for Automation When setting up CI/CD runners or server-side scripts, use SSH Keys instead of HTTPS. They are more secure and don't require manual password/token input during automated pushes.

Git Cheat Sheet Remote Branches