What is a remote repository and why it exists

Published on 2026-09-12 by frfrand

Un remoto no es "la nube": es otra copia del repositorio a la que le pusiste un nombre. Qué hacen fetch, pull y push en realidad, y por qué conviene separar traer de integrar.

A remote repository sounds like "the repository in the cloud". It's a convenient and misleading description.

A remote is simply another copy of the repository, in another place, to which you gave a short name so you don't have to write the address every time.

$ git remote -v origin git@github.com:empresa/app.git (fetch) origin git@github.com:empresa/app.git (push)

"origin" has nothing special about it. It's the default name of the first one you configure. It could be called "github", "central" or "pepe".

Why it's needed, if Git is distributed

Technically it isn't needed. Two people could pull directly from each other's machines. Git supports it.

In practice it doesn't work: computers turn off, change networks, are behind routers. So the team agrees on a place that is always available, and that place becomes the meeting point.

The difference with previous centralized systems is subtle but important: that server is a convention, not a technical necessity. Its copy is no more "true" than yours; it's just always on.

Three commands, and one that confuses

git fetch downloads what's new on the remote and stores it separately, in references like origin/main. It doesn't touch your files or your branch. It's always safe to run, and it's the correct answer to "what's new?".

git merge origin/main integrates that into your current branch. That's where conflicts can appear.

git pull does both, one after the other.

That merging of steps is the cause of a very common feeling: that conflicts "appear out of nowhere". They don't appear out of nowhere; what happens is that pull did two things and you only saw the second one.

A habit worth having, especially in active teams:

git fetch git log --oneline HEAD..origin/main # what came in git merge origin/main # now yes

Three commands instead of one, and no surprises.

push, and why it is sometimes rejected

git push sends your commits to the remote. The remote accepts them only if your history contains theirs: that is, if you can advance without losing anything.

If someone uploaded something you don't have, the push is rejected. It is not an error: it is a protection. If it were accepted, that person's commits would be orphaned.

The correct solution is to bring in the new changes, integrate them, and push again.

And the incorrect solution, which appears in many answers on the Internet:

git push --force

That replaces the remote's history with yours, and the other person's work disappears from the remote. If forcing is truly necessary (for example, after rewriting your own branch), there is a much safer variant:

git push --force-with-lease

That fails if the remote changed since the last time you checked, instead of blindly overwriting.

Multiple remotes at once

Nothing forces you to have only one:

git remote add upstream git@github.com:original/proyecto.git git fetch upstream

It is the classic workflow when working on a fork: origin is your fork, upstream is the original project, and you pull from one and push to the other.

You can also have a remote that is your own server, and deploy with a direct push.

A short recommendation

Set up the remote via SSH, not HTTPS. With SSH you use your key, you don’t type passwords or tokens, and it works the same on your machine and on a CI server.

If you already have it set up via HTTPS:

git remote set-url origin git@github.com:empresa/app.git