Remotes y GitHub

docs.scrimba.com

Hasta ahora, cada repositorio de este manual ha vivido en un solo lugar: tu propia máquina. Eso funciona bien hasta que quieres un respaldo que sobreviva si tu laptop muere, quieres seguir trabajando en el proyecto desde otra computadora, o quieres que alguien más pueda tocar el código. Lo que necesitas es una copia del repositorio guardada en algún lugar al que todas las máquinas involucradas puedan acceder. A esa copia se le llama remote, y GitHub es donde la mayoría de los desarrolladores la guardan.

Qué es un remote (y qué papel juega GitHub)

Un remote es una copia de tu repositorio alojada en algún lugar distinto de tu propia máquina, casi siempre en GitHub. Cuando clonas un repositorio, Git ya configura uno por ti, llamado origin por defecto. Ejecuta git remote -v (el -v pide también las URLs, además de los nombres) para verlo:

$ git remote -v
origin  https://github.com/mara-chen/weather-app.git (fetch)
origin  https://github.com/mara-chen/weather-app.git (push)

Cada remote que Git conoce aparece listado dos veces, una para fetch y otra para push, porque en teoría podrían apuntar a direcciones distintas. En la práctica casi siempre es la misma. origin es el apodo que Git asigna automáticamente al clonar. Puedes renombrarlo o agregar un segundo remote que apunte a otro lugar, pero casi todos los proyectos con los que trabajes van a llamar origin a su remote principal.

Este es un buen momento para repetir la distinción que confunde a casi todos los que empiezan: Git y GitHub no son lo mismo. Git es la herramienta de control de versiones que corre en tu máquina, registrando commits sin importar si estás conectado a algo o no. GitHub es un sitio web que aloja una copia de tu repositorio y te da un remote al cual hacer push y desde el cual hacer pull. git remote, git push y git pull son los comandos que conectan ambos mundos: son la forma en que el Git de tu laptop se comunica con un repositorio que vive en los servidores de GitHub.

Un remote no es más que un nombre asociado a una URL, guardado en la configuración de tu repositorio. Junto a eso, Git mantiene una rama de seguimiento remoto (remote-tracking branch): un marcador local que registra dónde estaba una rama de ese remote la última vez que tu máquina se comunicó con él. origin/main es exactamente eso. No es la rama main real que está en GitHub. Es lo que tu repositorio recuerda sobre dónde estaba el main de GitHub la última vez que hiciste un fetch o un pull. Lista las ramas de seguimiento remoto que Git tiene guardadas con git branch -r:

$ git branch -r
origin/main

Todo lo que hace un remote pasa por esa entrada de configuración más estos marcadores de seguimiento. No hay ninguna conexión de fondo ni nada vigilando cambios. Git solo actualiza su idea de cómo está el remote cuando tú se lo pides, con fetch o pull, que es justo lo que cubre el resto de este capítulo.

JunoQué es un remote Un remote es una copia de tu repositorio alojada en otro lugar, normalmente en GitHub, y Git le llama origin al que se crea por defecto. Ejecuta git remote -v en cualquier momento para ver qué remotes conoce tu repositorio. Git y GitHub no son lo mismo: Git es la herramienta en tu máquina, GitHub es donde suele vivir tu remote. Tener esa distinción clara desde el principio te ahorra mucha confusión más adelante.

JunoQué es un remoteorigin es solo el nombre por defecto que Git le da al remote que configura al clonar, así que puedes renombrarlo o agregar más remotes cuando un proyecto lo necesite. git remote -v muestra la URL de cada remote, tanto para fetch como para push. Ten siempre presente la diferencia entre Git y GitHub: los comandos que ejecutas localmente son Git, y GitHub es uno de varios destinos a los que esos comandos pueden llegar.

JunoQué es un remote Un remote es un nombre asociado a una URL en tu configuración, junto con ramas de seguimiento remoto como origin/main, que es lo que tu máquina recuerda sobre dónde estaba esa rama en tu último fetch o pull. Nada se actualiza solo; Git solo revisa el remote cuando se le pide. Esa brecha entre lo que realmente tiene GitHub y lo que tu rama de seguimiento remoto recuerda es la causa de casi todas las sorpresas entre fetch y pull.

Dónde alojar tu remote: GitHub y las alternativas

Todo lo que hace un remote es Git puro y simple, y eso tiene una consecuencia que vale la pena conocer desde el principio: el proveedor del otro lado se puede cambiar. Para Git, cada proveedor es solo una URL en tu configuración, y git push, git pull y git fetch se comportan igual con todos ellos. Lo que un proveedor agrega está un nivel más arriba: una vista web de tu código, un flujo de revisión, seguimiento de issues y control de acceso. Aquí está el panorama, con las ventajas y desventajas dichas sin rodeos:

• GitHub es, por mucho, el más grande, y alberga la gran mayoría del trabajo open-source. Su fortaleza es la red: los proyectos a los que quieres contribuir ya están ahí, los tutoriales lo asumen, y los empleadores buscan tu perfil en él. La desventaja es que es una plataforma cerrada (propiedad de Microsoft), y cuanto más dependas de sus funciones extra más allá del alojamiento de Git, más atado quedas a ella.
• GitLab es la alternativa completa más cercana, con las mismas funciones principales bajo nombres un poco distintos (ahí los pull requests se llaman "merge requests"). Su punto fuerte es una edición autoalojada que puedes correr en tus propios servidores, razón por la cual las empresas que mantienen su código en casa suelen elegirla. La desventaja es que incluye muchísimas funciones, y la plataforma puede sentirse más pesada que el simple alojamiento de código que buscabas.
• Bitbucket es el proveedor de Atlassian, pensado para integrarse con sus herramientas de seguimiento de proyectos y documentación, Jira y Confluence. Si tu equipo ya vive en esas herramientas, encaja de inmediato. Fuera de ese ecosistema tiene la comunidad más pequeña de los tres grandes y poca presencia en open-source.
• Codeberg es un proveedor sin fines de lucro para proyectos open-source, que corre sobre la plataforma open-source Forgejo. Su atractivo es que ninguna empresa es dueña del proveedor y la plataforma misma es de código abierto. La desventaja es la escala: menos integraciones, una comunidad más pequeña, y un enfoque en open-source más que en trabajo privado de equipo.
• Autoalojamiento: es la base de todo lo anterior: puedes correr Forgejo o Gitea, ambos gratuitos y de código abierto, o la edición autoalojada de GitLab en hardware que tú controlas. Ganas control total y privacidad; la desventaja es que mantenerlo funcionando pasa a ser tu trabajo.

Este manual usa GitHub en sus ejemplos porque ahí se aloja la mayor parte del trabajo open-source y es donde más probablemente colabores por primera vez. Todos los comandos de este capítulo se aplican sin cambios a cualquier otro proveedor: cambia la URL y el ciclo diario de trabajo sigue siendo el mismo. Las diferencias están un nivel más arriba, en la interfaz web de cada sitio para revisar y fusionar trabajo, que es justo lo que veremos en el flujo de pull requests del próximo capítulo.

Cuando la decisión es tuya, casi nunca depende de las funciones de Git, porque el conjunto básico (repositorios alojados, revisiones, issues, pipelines de CI) existe en todos lados. Todo se reduce al contexto: contribuir a open-source o construir un perfil público apunta a GitHub, una empresa que trabaja con herramientas de Atlassian apunta a Bitbucket, código que debe permanecer en tu propia infraestructura apunta a GitLab autoalojado o Forgejo, y un proyecto open-source con una fuerte identidad de valores puede sentirse más cómodo en Codeberg. Tampoco es una decisión permanente. Mover el repositorio mismo entre proveedores es solo un git remote set-url más un push; la parte costosa de una migración es la capa por encima de Git: los issues, wikis y configuración de CI, que no se mueven junto con los commits.

El autoalojamiento merece una mirada honesta antes de que te comprometas con él. Forgejo y Gitea corren sin problema en un servidor pequeño, pero la carga operativa es real: actualizaciones de seguridad, respaldos tanto de los repositorios como de la propia base de datos de la plataforma, gestión de cuentas y llaves SSH, y disponibilidad, porque un forge caído bloquea cada push y pull de tu equipo. Vale la pena cuando las reglas de cumplimiento exigen que el código no salga de tu propia infraestructura, en entornos aislados de red, o cuando una organización quiere tener sus herramientas bajo su propio control. Por debajo de la capa web nada cambia: todos estos proveedores hablan el mismo protocolo de Git, razón por la cual tu push y tu fetch no pueden distinguir a uno de otro.

JunoDónde alojar tu remote GitHub es donde vive la mayoría de los proyectos y la opción más segura por defecto cuando estás empezando, pero es solo uno entre varios proveedores: GitLab, Bitbucket y el sin fines de lucro Codeberg guardan los mismos repositorios de Git. Push y pull funcionan igual sin importar dónde viva el remote, así que nada de lo que aprendas aquí se pierde si un proyecto vive en otro lado.

JunoDónde alojar tu remote Los proveedores se diferencian un nivel por encima de Git: GitLab llama "merge requests" a los pull requests y ofrece una edición autoalojada, Bitbucket se conecta con las herramientas de Atlassian, y Codeberg corre sobre el Forgejo open-source. Elige según dónde ya estén tus colaboradores y tus herramientas, y recuerda que un cambio de proveedor más adelante es económico del lado de Git; lo que no se mueve son los issues y el CI.

JunoDónde alojar tu remote Como un remote es solo un nombre asociado a una URL, mover un proyecto entre proveedores es un git remote set-url más un push. Autoalojar Forgejo o Gitea te da control y privacidad, y te cuesta parches, respaldos y disponibilidad; toma esa opción cuando la política lo exija, no por gusto, dice quien ya ha cargado con esa responsabilidad. Todo lo específico de cada proveedor vive en la capa web por encima del protocolo de Git.

Enviar y traer tu trabajo: git push y git pull

Con un remote configurado, dos comandos cubren la mayor parte del trabajo diario. git push envía tus commits locales al remote. git pull trae los commits hechos en otro lado y los fusiona en la rama en la que estás.

$ git push origin main
Enumerating objects: 5, done.
Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
To https://github.com/mara-chen/weather-app.git
   9f8e7d6..a1b2c3d  main -> main

origin es el remote, main es la rama que estás enviando. Esa última línea es la que vale la pena leer: muestra cómo main en el remote pasa de un commit al siguiente.

Hacer pull funciona igual, pero al revés:

$ git pull origin main
remote: Enumerating objects: 4, done.
Unpacking objects: 100% (4/4), done.
Updating a1b2c3d..b7c9e21
Fast-forward
 src/index.js | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Ese es todo el ciclo para trabajar junto a otras personas en un mismo proyecto: traer con pull lo que haya cambiado antes de empezar, hacer tu propio trabajo y confirmarlo, y luego subirlo con push. Haz pull antes de hacer push siempre que compartas una rama con alguien más. Si te saltas el pull, tu push podría intentar aterrizar encima de commits que nunca viste, y Git se va a negar a hacerlo antes que arriesgarse a perder el trabajo de alguien.

La primera vez que haces push de una rama nueva, agrega -u (abreviatura de --set-upstream):

$ git push -u origin feature/add-forecast-icons
Enumerating objects: 5, done.
Writing objects: 100% (5/5), 412 bytes | 412.00 KiB/s, done.
To https://github.com/mara-chen/weather-app.git
 * [new branch]      feature/add-forecast-icons -> feature/add-forecast-icons
branch 'feature/add-forecast-icons' set up to track 'origin/feature/add-forecast-icons'.

Eso registra que feature/add-forecast-icons sigue a origin/feature/add-forecast-icons, un vínculo llamado upstream. Una vez configurado, cada push y pull posterior puede omitir el nombre del remote y de la rama, y ejecutarse simplemente como git push o git pull en esa rama. Si una rama todavía no tiene upstream configurado, Git te lo dice e imprime el comando exacto para arreglarlo, así que casi nunca necesitas memorizar el flag, solo reconocer el mensaje cuando aparezca.

Ese vínculo de upstream vive como dos líneas simples escritas en la configuración de tu repositorio en el momento en que se ejecuta -u: branch.feature/add-forecast-icons.remote indica el remote, branch.feature/add-forecast-icons.merge indica la rama en él. Ejecuta git config --get branch.main.remote en una rama que ya hayas subido antes y verás exactamente ese valor de regreso. Esas dos líneas son también lo que git status lee para decirte que tu rama está dos commits adelante de origin/main, o que ambas se han separado: la comparación se hace por completo contra tu rama de seguimiento remoto, una verificación local que no trae nada de GitHub. Configura el upstream una vez, y cada conteo de "adelante/atrás" que Git te muestre después está leyendo ese mismo par de líneas de configuración.

JunoEnviar y traer tu trabajogit push envía tus commits al remote, y git pull trae los commits hechos en otro lado y los fusiona en tu rama. Haz pull antes de empezar a trabajar y push cuando termines, y así te mantienes sincronizado con cualquier otra persona que toque el proyecto. Saltarse el pull es la razón más común por la que un push es rechazado.

JunoEnviar y traer tu trabajogit push origin main envía commits, git pull origin main los trae y los fusiona, y una vez que una rama tiene un upstream configurado con git push -u, ambos comandos funcionan sin necesidad de volver a indicar el remote o la rama. Haz pull antes de hacer push en una rama compartida, o tu push será rechazado porque el remote ya avanzó más allá de tu historial local.

JunoEnviar y traer tu trabajo El upstream que configuras con git push -u se reduce a dos líneas de configuración, branch.<nombre>.remote y branch.<nombre>.merge, escritas en el momento en que se ejecuta el flag. git status lee ese mismo par para decirte qué tan adelante o atrás está tu rama de origin/main, una comparación que hace por completo contra tu rama de seguimiento remoto local. Configúralo una vez por rama y cada push o pull abreviado, y cada conteo de adelante/atrás, viene gratis.

git fetch vs git pull

git pull hace dos cosas en un solo paso: descarga lo que haya cambiado en el remote, y luego fusiona de inmediato esos cambios en la rama en la que estás. git fetch solo hace la primera mitad. Descarga los commits nuevos pero nunca los fusiona en tu rama. Tu rama actual, y tus archivos de trabajo, se quedan exactamente igual hasta que le pidas a Git que haga el merge o el pull.

Este es el tropiezo con el que casi todos se encuentran al menos una vez: ejecutas git fetch, no ves ningún cambio visible en ningún lado, y asumes que no pasó nada en el remote. Sí pasó algo: fetch todavía no ha tocado tu rama de trabajo. Para ver qué llegó, revisa la rama de seguimiento remoto de la que hablamos antes en este capítulo: git log origin/main muestra los commits que están en el remote y que todavía no han llegado a tu main local. Cuando estés listo para traerlos, git merge origin/main lo hace, o git pull ejecuta el fetch y ese merge por ti en un solo comando.

Recurre a fetch solo cuando quieras revisar antes de fusionar. Digamos que una compañera, Priya, menciona que hizo push de algo a main: git fetch seguido de git log origin/main o git diff main origin/main te permite leer exactamente qué cambió antes de que llegue a tu rama de trabajo. Una vez que estés conforme, git merge origin/main lo trae. En el día a día, la mayoría recurre directamente a git pull, porque ver y fusionar en un solo paso es justo lo que quieren de todos modos. Fetch se justifica en una rama compartida donde prefieras leer primero el trabajo entrante, o antes de decidir si este es un buen momento para fusionar siquiera.

Lo que fetch realmente actualiza está determinado por un refspec: un mapeo, guardado en la configuración de tu remote, que le dice a Git qué ramas del remote traer y bajo qué nombres locales guardarlas. El refspec por defecto en un clon normal se ve más o menos como +refs/heads/*:refs/remotes/origin/*, lo que significa "toma cada rama bajo los heads del remote y refléjala en mis ramas de seguimiento remoto, moviéndolas para que coincidan aunque eso sobrescriba a qué apuntaban antes". Ese es todo el mecanismo detrás de que origin/main se mantenga actualizado: fetch lee las ramas del remote y reescribe tus ramas de seguimiento remoto para que coincidan, y ahí se detiene. Nada en tu propio main cambia hasta que un merge, rebase o pull aparte actúe sobre lo que fetch trajo.

Junogit fetch vs git pullgit pull descarga commits nuevos y los fusiona en tu rama en un solo paso. git fetch solo los descarga y actualiza lo que Git recuerda sobre el estado del remote; tu rama se queda igual hasta que hagas el merge. No ver ningún cambio en tus archivos justo después de un fetch es normal, los commits nuevos están esperando en la rama de seguimiento remoto.

Junogit fetch vs git pullgit fetch descarga sin fusionar, git pull descarga y fusiona en un solo paso. Recurre a fetch solo cuando quieras leer los commits entrantes con git log origin/main antes de que lleguen a tu rama, y usa pull cuando estés listo para fusionarlos de inmediato. Confundir los dos es uno de los errores de Git más comunes en un equipo.

Junogit fetch vs git pull Un refspec decide exactamente qué trae fetch y qué ramas de seguimiento remoto actualiza, origin/main incluida, y el refspec por defecto refleja cada rama bajo los heads del remote. Fetch únicamente mueve tus ramas de seguimiento remoto, nunca tu rama activa, así que fusionar o hacer pull sigue siendo un paso separado y deliberado.

Hasta dónde llegas con esto

Push, pull y fetch llevan tus commits a un remote compartido y los traen de vuelta, y eso cubre la mayor parte de lo que exige la colaboración diaria en Git. Todo esto se apoya en el ciclo de commits: sigues haciendo stage y commit localmente primero, un remote solo cambia hasta dónde pueden viajar esos commits. La siguiente pieza es hacer esa colaboración a través de GitHub mismo, proponer un cambio y que sea revisado antes de fusionarse. El flujo de pull requests continúa justo desde ahí. Si algún término de este capítulo todavía se siente poco claro, rama de seguimiento remoto, refspec, upstream, el Glosario tiene una definición simple para cada uno, y Qué es Git vale la pena revisarlo de nuevo para la distinción entre Git y GitHub por sí sola.