A Remote Repository is a version of your project hosted on a network, which serves as a centralization and synchronization point for collaborative work.
So far, our entire course has taken place in “The Shire”. We have worked on our hard drive, safe and isolated.
But Git is a tool designed for collaborative work. Its true power is unleashed when we connect our local repository with a Remote Repository hosted on the internet (services like GitHub, GitLab, or Bitbucket).
Today we are going to understand how that invisible cable connecting your computer to the server works. We are going to talk about remotes.
What is a Remote?
In technical terms, for Git a remote is nothing more than a reference to a URL. Basically, it’s an entry in our project’s address book.
Suppose you want to send your code to a server whose address is:
It would be quite a pain to have to type that long URL every time you want to sync changes with your remote.
To avoid this, Git allows us to assign an alias (a short name) to that URL. That alias is the remote.
The (non) Keyword origin
When you use Git with remotes, you’ll end up seeing the word origin everywhere. What does it really mean? Nothing.
Origin is simply the default name that Git gives to the first cloud repository when you clone it or add it.
It is purely a convention, not a command or reserved word in itself.
You could call your remote server, cloud, github, or pepito. Git doesn’t care. We use origin because it’s the industry standard and we all understand each other.
Managing Remotes
Although remotes are usually configured automatically when you clone, sometimes we need to manage them manually.
To see what remotes your current repository has configured, use the command:
git remote -v
The -v is for verbose, so it also shows the URL.
You will see something like this:
origin https://github.com/usuario/repo.git (fetch)
origin https://github.com/usuario/repo.git (push)
This means: “I have a saved contact named ‘origin’ that points to this web address”.
If you have created a local repository with git init and now want to upload it to an empty repo you created on GitHub:
git remote add origin https://github.com/tu-usuario/tu-repo.git
Here we are telling Git: “Git, add a new remote named origin that points to this URL”.
If you change your repo name on GitHub or decide to switch from HTTPS to SSH, you need to update the address:
git remote set-url origin [email protected]:tu-usuario/tu-repo.git
To rename a remote we do:
git remote rename origin destino # Change the name
To delete a remote we do:
git remote remove origin # Delete the remote
Connection Protocols: HTTPS or SSH?
When you create a repository on GitHub or GitLab, you’ll see they offer two types of URLs to clone it: HTTPS and SSH.
Which one should you choose? This is one of the most frequent questions. Let’s see the differences.
HTTPS Protocol
It’s the URL that starts with https://....
- How it works: It’s the same protocol you use to browse the web.
- Authentication: Uses username and password (or Token).
- Pros: It’s universal. It works on any network, even behind strict corporate firewalls (because it uses port 443, the web port). It’s very easy to understand.
- Cons (Old): Before, you had to type your username and password EVERY time you did a push. A nightmare.
- Cons (Modern): GitHub removed password support in 2021. Now you need to create a Personal Access Token (PAT) and configure it. Fortunately, modern “Credential Helpers” on Windows and Mac save it for you.
Who is it for? For beginners or if you are on a restricted network (university, strict office).
SSH Protocol
It’s the URL that starts with [email protected]:....
- How it works: It uses a pair of cryptographic keys (public and private).
- Authentication: You have a key on your computer (private) and you give the lock (public) to GitHub. When you try to connect, GitHub checks if the key fits.
- Pros: Total security and convenience. Once configured, it never asks for a password again. Git knows it’s you because you have the key on your hard drive.
- Cons: Requires an initial setup that scares novices a bit (generating keys, copying them, etc.). Also, the SSH port (22) is sometimes blocked on public or corporate Wi-Fi networks.
Who is it for? For developers. It’s the de facto standard for day-to-day work.
If you are going to work with Git, switch to SSH. Those couple of extra minutes of initial setup will save you from typing hundreds of passwords throughout the year.
