Un Repositorio Remoto es una versión de tu proyecto alojada en red, que sirve como punto de centralización y sincronización para el trabajo colaborativo.
Hasta ahora, todo nuestro curso ha transcurrido en “La Comarca”. Hemos trabajado en nuestro disco duro, seguros y aislados.
Pero Git es una herramienta diseñada para el trabajo colaborativo. La verdadera potencia se desata cuando conectamos nuestro repositorio local con un Repositorio Remoto alojado en internet (servicios como GitHub, GitLab o Bitbucket).
Hoy vamos a entender cómo funciona ese cable invisible que conecta tu ordenador con el servidor. Vamos a hablar de remotos.
¿Qué es un Remote?
En términos técnicos, para Git un remote no es más que una referencia a una URL. Básicamente es una entrada en la agenda de contactos de nuestro proyecto.
Supongamos que quieres enviar tu código a un servidor cuya dirección es:
Sería bastante peñazo tener que escribir esa URL kilométrica cada vez que quieras sincronizar los cambios con tu remoto.
Para evitar esto, Git nos permite asignar un alias (un nombre corto) a esa URL. Ese alias es el remoto.
La (no) palabra clave origin
Cuando uses Git con remotos, acabarás viendo la palabra origin hasta en la sopa. ¿Qué significa realmente? Nada.
Origin es simplemente el nombre por defecto que Git le da al primer repositorio en la nube cuando lo clonas o lo añades.
Es puramente una convención, no es un comando o palabra reservada en sí misma.
Podrías llamar a tu remoto servidor, nube, github o pepito. A Git le da igual. Usamos origin porque es el estándar de la industria y todos nos entendemos.
Gestionando Remotos
Aunque generalmente los remotos se configuran solos al hacer clone, a veces necesitamos gestionarlos a mano.
Para ver qué remotos tiene configurados tu repositorio actual, usa el comando:
git remote -v
La -v es de verbose, para que nos enseñe también la URL.
Verás algo así:
origin https://github.com/usuario/repo.git (fetch)
origin https://github.com/usuario/repo.git (push)
Esto significa: “Tengo un contacto guardado llamado ‘origin’ que apunta a esta dirección web”.
Si has creado un repositorio local con git init y ahora quieres subirlo a un repo vacío que has creado en GitHub:
git remote add origin https://github.com/tu-usuario/tu-repo.git
Aquí le estamos diciendo: “Git, añade un nuevo remoto llamado origin que apunte a esta URL”.
Si cambias de nombre tu repo en GitHub o decides pasar de HTTPS a SSH, necesitas actualizar la dirección:
git remote set-url origin [email protected]:tu-usuario/tu-repo.git
Para renombrar un remoto hacemos
git remote rename origin destino # Cambiar el nombre
Para borrar un remoto hacemos
git remote remove origin # Borrar el remoto
Protocolos de conexión: ¿HTTPS o SSH?
Cuando creas un repositorio en GitHub o GitLab, verás que te ofrecen dos tipos de URL para clonarlo: HTTPS y SSH.
¿Cuál deberías elegir? Esta es una de las dudas más frecuentes. Vamos a ver las diferencias.
Protocolo HTTPS
Es la URL que empieza por https://....
- Cómo funciona: Es el mismo protocolo que usas para navegar por la web.
- Autenticación: Usa usuario y contraseña (o Token).
- Pros: Es universal. Funciona en cualquier red, incluso detrás de firewalls corporativos estrictos (porque usa el puerto 443, el de la web). Es muy fácil de entender.
- Contras (Antiguos): Antes, tenías que escribir tu usuario y contraseña CADA vez que hacías un push. Un infierno.
- Contras (Modernos): GitHub eliminó el soporte de contraseñas en 2021. Ahora necesitas crear un Personal Access Token (PAT) y configurarlo. Afortunadamente, los “Credential Helpers” modernos de Windows y Mac lo guardan por ti.
¿Para quién es? Para principiantes o si estás en una red restringida (universidad, oficina estricta).
Protocolo SSH
Es la URL que empieza por [email protected]:....
- Cómo funciona: Utiliza un par de claves criptográficas (pública y privada).
- Autenticación: Tú tienes una llave en tu ordenador (privada) y le das la cerradura (pública) a GitHub. Cuando intentas conectar, GitHub comprueba si la llave encaja.
- Pros: Seguridad y comodidad total. Una vez configurado, no te pide contraseña nunca más. Git sabe que eres tú porque tienes la llave en tu disco duro.
- Contras: Requiere una configuración inicial que asusta un poco a los novatos (generar claves, copiarlas, etc.). Además, el puerto SSH (22) a veces está bloqueado en redes Wi-Fi públicas o corporativas.
¿Para quién es? Para desarrolladores. Es el estándar de facto para trabajar día a día.
Si vas a trabajar con Git, pásate a SSH. Ese par de minutos extra de configuración inicial te ahorrará teclear cientos de contraseñas a lo largo del año.
