Cuando hablamos de remotos en Git, nos adentramos en la forma en que distribuimos código entre diferentes repositorios a través de una red o Internet. Git es un sistema de control de versiones distribuido, lo que significa que no existe una relación estricta de cliente-servidor como en otros sistemas centralizados, por ejemplo, SVN.
En sistemas centralizados como SVN, cada desarrollador tiene una copia local del repositorio, pero siempre está sincronizada con un repositorio central que actúa como servidor. Esto implica que para cualquier operación, la copia local debe comunicarse con ese servidor, lo que puede generar problemas si no hay conexión a Internet. Este modelo funciona bien para proyectos individuales, pero en entornos colaborativos es fundamental porque todos acceden a un único punto central que refleja el estado actual del código.
Git, en cambio, rompe con esta idea. No hay un servidor central obligatorio; en lugar de eso, cada repositorio local es un nodo independiente dentro de una red de nodos. Estos nodos pueden comunicarse entre sí para intercambiar código mediante operaciones conocidas como push y pull. Así, podemos enviar cambios a otro nodo o recibirlos de él sin necesidad de un servidor central.
Para gestionar estas conexiones, Git dispone del subcomando remote. Si ejecutamos git remote sin argumentos, no veremos nada si no hemos configurado remotos, pero este comando nos permite agregar y listar remotos, es decir, otros repositorios con los que queremos interactuar. Una vez configurados, podemos usar git push para enviar cambios a un remoto y git pull para traer cambios desde él.
Imaginemos que estamos trabajando en una oficina con un compañero. Su repositorio puede ser un remoto para nosotros. Cuando queremos compartir código, hacemos un push a su repositorio, o él puede hacer un pull del nuestro; ambas acciones logran el mismo objetivo. Lo mismo ocurre si queremos obtener código de nuestro compañero: podemos hacer un pull de su repositorio o él puede hacer un push al nuestro.
En redes más grandes, donde muchos desarrolladores trabajan simultáneamente, no es práctico que todos los nodos se comuniquen directamente entre sí, ya que esto generaría una cantidad enorme de conexiones. Por eso, suele existir un repositorio central, un nodo especial que actúa como punto de referencia para todos. Aunque Git es distribuido, este repositorio central, al que a veces llamamos “repositorio sagrado”, facilita la coordinación y sirve como copia segura del código.
Este modelo es el que utilizan plataformas como GitHub, Bitbucket o GitLab. Aunque Git no requiere un servidor central, estas plataformas funcionan como nodos más dentro de la red, ofreciendo una copia accesible y segura del código en la nube. Sin embargo, nada nos obliga a enviar siempre los cambios a GitHub; podemos hacer push directamente al repositorio de un compañero o a otro nodo sin pasar por un servidor central.
Es importante recordar que, aunque dependemos mucho de servicios como GitHub, en realidad podemos seguir trabajando localmente sin conexión y sincronizar cambios cuando sea posible. La caída de un servidor central no debería paralizar nuestro trabajo, ya que cada repositorio local es completo y funcional por sí mismo.
En próximos pasos, exploraremos cómo agregar remotos con comandos específicos, cómo enviar y recibir cambios, y cómo trabajar con remotos que estén en nuestra misma red local usando SSH. También veremos cómo interactuar con repositorios alojados en servicios en la nube como GitHub o Bitbucket. Además, descubriremos que los remotos no tienen que estar necesariamente en otro ordenador; pueden estar en nuestro propio equipo, facilitando pruebas y sincronizaciones locales antes de compartir con otros.