Remotos y GitHub

docs.scrimba.com

Cada repositorio en este manual hasta ahora ha vivido en un solo lugar: tu propia máquina. Eso funciona bien hasta que necesitas una copia de seguridad que sobreviva a una laptop rota, quieres retomar el proyecto desde una segunda computadora, o quieres que alguien más toque el código. Lo que necesitas es una copia del repositorio en algún lugar al que cada máquina involucrada pueda acceder. Esa copia se llama remoto, y GitHub es donde la mayoría de los desarrolladores la ponen.

Qué es un remoto (y dónde encaja GitHub)

Un remoto es una copia de tu repositorio alojada en algún lugar que no sea tu propia máquina, generalmente en GitHub. Cuando clonas un repositorio, Git ya configura uno para ti, llamado origin por defecto. Ejecuta git remote -v (el -v solicita 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 remoto que Git conoce se lista dos veces, una para buscar y otra para enviar, porque en teoría los dos podrían apuntar a direcciones diferentes. En la práctica casi siempre son iguales. origin es el apodo que Git asigna automáticamente al clonar. Puedes renombrarlo o añadir un segundo remoto apuntando a otro lugar, pero casi cada proyecto que toques llamará a su remoto principal origin.

Este es un buen momento para reafirmar la distinción que confunde a casi todos los que comienzan: Git y GitHub no son lo mismo. Git es la herramienta de control de versiones ejecutándose en tu máquina, registrando commits independientemente de si estás conectado a algo. GitHub es un sitio web que aloja una copia de tu repositorio y te proporciona un remoto hacia el que enviar y desde el que traer cambios. git remote, git push, y git pull son los comandos que conectan los dos: es cómo el Git que se ejecuta en tu laptop habla con un repositorio en los servidores de GitHub.

Un remoto no es nada más que un nombre asignado a una URL, almacenado en la configuración de tu repositorio. Junto a él, Git mantiene una rama de seguimiento remoto: un marcador local que registra dónde estaba una rama en ese remoto la última vez que tu máquina hizo una verificación. origin/main es exactamente eso. No es la rama main actual en GitHub. Es la memoria de tu repositorio de dónde estaba main de GitHub en tu último fetch o pull. Lista las ramas de seguimiento remoto que Git actualmente tiene con git branch -r:

$ git branch -r
origin/main

Todo lo que un remoto hace se ejecuta a través de esa entrada de configuración más estos marcadores de seguimiento. No hay una conexión de fondo y nada vigilando cambios. Git solo actualiza su imagen del remoto cuando se lo indicas, con fetch o pull, que es exactamente lo que el resto de este capítulo cubre.

JunoQué es un remoto Un remoto es una copia de tu repositorio alojada en otro lugar, generalmente en GitHub, y Git llama al predeterminado origin. Ejecuta git remote -v en cualquier momento para ver qué remotos conoce tu repositorio. Git y GitHub no son lo mismo: Git es la herramienta en tu máquina, GitHub es donde tu remoto generalmente vive. Resolver esa diferencia desde el principio evita mucha confusión después.

JunoQué es un remotoorigin es solo el nombre predeterminado que Git asigna al remoto que configura al clonar, así que puedes renombrarlo o agregar más remotos cuando un proyecto lo necesita. git remote -v muestra la URL de cada remoto tanto para fetch como para push. Mantén 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 remoto Un remoto es un nombre asignado a una URL en tu configuración, emparejado con ramas de seguimiento remoto como origin/main, la memoria de tu máquina de dónde estaba esa rama en tu último fetch o pull. Nada se actualiza por sí solo; Git solo verifica el remoto cuando se le pide. Esa brecha entre lo que GitHub realmente tiene y lo que tu rama de seguimiento remoto recuerda está detrás de casi todas las sorpresas de fetch-versus-pull.

Dónde alojar tu remoto: GitHub y las alternativas

Todo lo que un remoto hace es Git puro, y eso tiene una consecuencia que vale la pena conocer desde temprano: el host en el otro extremo es intercambiable. Para Git, cada host es una URL en tu configuración, y git push, git pull, y git fetch se comportan idénticamente contra todos ellos. Lo que un host añade se sitúa un nivel arriba: una vista web de tu código, un flujo de revisión, seguimiento de problemas, y control de acceso. Aquí está el panorama, con los equilibrios establecidos claramente:

• GitHub es el más grande por lejos y aloja la gran mayoría del trabajo de código abierto. Su fortaleza es la red: los proyectos a los que quieres contribuir ya están allí, los tutoriales lo asumen, y los empleadores buscan tu perfil en él. El equilibrio es que es una plataforma cerrada (propiedad de Microsoft), y cuanto más dependas de sus funciones adicionales más allá del alojamiento de Git, más atado a ella te vuelves.
• GitLab es la alternativa completa más cercana, con las mismas características principales bajo nombres ligeramente diferentes (las solicitudes de extracción se llaman "solicitudes de fusión" allí). Su punto destacado es una edición autoadministrada que puedes ejecutar en tus propios servidores, razón por la cual las empresas que mantienen código internamente a menudo la eligen. El equilibrio es que empaqueta mucho, y la plataforma puede sentirse más pesada que el alojamiento de código que buscabas.
• Bitbucket es el host de Atlassian, construido para sentarse al lado de sus herramientas de seguimiento de proyectos y documentación, Jira y Confluence. Si tu equipo ya vive en esas herramientas, se ajusta directamente. Fuera de ese ecosistema tiene la comunidad más pequeña de los tres grandes y poca presencia de código abierto.
• Codeberg es un host sin fines de lucro para proyectos de código abierto, ejecutado en la plataforma de código abierto Forgejo. El atractivo es que ninguna empresa posee tu host y la plataforma misma es código abierto. El equilibrio es escala: menos integraciones, una comunidad más pequeña, y un enfoque en código abierto en lugar de trabajo en equipo privado.
• Auto-hospedaje subyace a todos estos: ejecuta Forgejo o Gitea, ambos gratuitos y de código abierto, o la edición autoadministrada de GitLab en hardware que controlas. Obtienes control total y privacidad; el equilibrio es que mantenerlo funcionando se convierte en tu trabajo.

Este manual usa GitHub en sus ejemplos porque aloja la mayoría del trabajo de código abierto y es donde probablemente colaborarás primero. Cada comando en este capítulo se transfiere sin cambios a cualquier otro host: cambia la URL y el ciclo diario sigue igual. Las diferencias viven un nivel arriba, en la interfaz web de cada sitio para revisar y fusionar trabajo, que es donde el flujo de solicitud de extracción del próximo capítulo entra en juego.

Cuando la opción es tuya para hacer, rara vez se trata de características de Git, porque el conjunto principal (repositorios alojados, revisiones, problemas, tuberías de CI) existe en todas partes. Se reduce al contexto: contribuir a código abierto o construir un perfil público apunta a GitHub, una empresa que se ejecuta en herramientas de Atlassian apunta a Bitbucket, código que debe permanecer en tu propia infraestructura apunta a GitLab autoadministrado o Forgejo, y un proyecto de código abierto impulsado por valores puede sentirse más en casa en Codeberg. La opción tampoco es para siempre. Mover el repositorio entre hosts es uno git remote set-url más un push; la parte costosa de una migración es la capa superior a Git, los problemas, wikis, y configuración de CI, que no viajan con los commits.

Auto-hospedaje merece una mirada clara antes de que te comprometas con él. Forgejo y Gitea se ejecutan cómodamente en un servidor pequeño, pero la carga operativa es real: actualizaciones de seguridad, copias de seguridad tanto de los repositorios como de la propia base de datos de la plataforma, gestión de cuentas y claves SSH, y tiempo de actividad, porque un forge caído bloquea cada push y pull que tu equipo intenta hacer. Se justifica cuando las reglas de cumplimiento mantienen código fuera de la infraestructura de terceros, en entornos desconectados, o cuando una organización quiere sus herramientas bajo su propio control. Debajo de la capa web nada cambia: cada uno de estos hosts habla el mismo protocolo Git, razón por la cual tu push y fetch no pueden distinguirlos.

JunoDónde alojar tu remoto GitHub es donde viven la mayoría de los proyectos y el valor predeterminado más seguro cuando estás comenzando, pero es uno de varios hosts: GitLab, Bitbucket, y el Codeberg sin fines de lucro almacenan los mismos repositorios de Git. Push y pull funcionan igual sin importar dónde vive el remoto, así que nada de lo que aprendas aquí se pierde si un proyecto vive en otro lugar.

JunoDónde alojar tu remoto Los hosts difieren un nivel arriba de Git: GitLab llama solicitudes de fusión a las solicitudes de extracción y ofrece una edición autoadministrada, Bitbucket se conecta a las herramientas de Atlassian, y Codeberg se ejecuta en el Forgejo de código abierto. Elige basándote en dónde tus colaboradores y herramientas ya están, y recuerda que una migración posterior es barata en el lado de Git; son los problemas y CI los que no viajan.

JunoDónde alojar tu remoto Dado que un remoto es un nombre asignado a una URL, mover un proyecto entre hosts es git remote set-url más un push. Auto-alojar Forgejo o Gitea compra control y privacidad y te cuesta aplicar parches, copias de seguridad, y tiempo de actividad; toma ese equilibrio cuando la política lo exige, no por diversión, dice la persona que ha cargado el buscapersonas para uno. Todo lo específico del host vive en la capa web por encima del protocolo Git.

Enviar y obtener tu trabajo: git push y git pull

Con un remoto en su lugar, dos comandos cubren la mayoría del trabajo diario. git push envía tus commits locales al remoto. git pull trae commits hechos en otro lugar 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 remoto, main es la rama que estás enviando. Esa última línea es la parte que vale la pena leer: muestra main en el remoto moviéndose de un commit al siguiente.

Tirar funciona de la misma manera, en reversa:

$ 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 el ciclo completo para trabajar junto a otras personas en un proyecto: trae lo que cambió antes de comenzar, haz tu propio trabajo y confirma, envíalo de nuevo hacia arriba. Trae antes de enviar siempre que compartas una rama con otra persona. Salta el pull y tu push puede aterrizar encima de commits que nunca viste, que Git rechazará en lugar de arriesgarse a perder el trabajo de alguien.

La primera vez que envías una rama nueva, añade -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 feature/add-forecast-icons como rastreando origin/feature/add-forecast-icons, un enlace llamado la rama ascendente. Una vez configurado, cada push y pull después de eso pueden soltar el nombre del remoto y rama y ejecutar simple git push o git pull en la rama. Si una rama aún no tiene una rama ascendente configurada, Git lo dice e imprime el comando exacto para arreglarlo, así que rara vez necesitas recordar la bandera, solo reconocer el mensaje cuando aparece.

Ese enlace ascendente vive como dos líneas simples escritas en la configuración de tu repositorio el momento en que -u se ejecuta: branch.feature/add-forecast-icons.remote nombra el remoto, branch.feature/add-forecast-icons.merge nombra la rama en él. Ejecuta git config --get branch.main.remote en una rama que hayas enviado antes y verás exactamente ese valor volver. Esas dos líneas son también lo que git status lee para decirte que tu rama está dos commits por delante de origin/main, o que los dos se han distanciado: la comparación se ejecuta enteramente contra tu rama de seguimiento remoto, una verificación local sin nada buscado de GitHub. Configura el remoto ascendente una vez, y cada conteo adelante-atrás que Git te muestra después es leyendo ese mismo par de líneas de configuración.

JunoEnviar y obtener tu trabajogit push envía tus commits hacia arriba al remoto, y git pull trae commits hechos en otro lugar y los fusiona en tu rama. Trae antes de comenzar a trabajar y envía cuando termines, y te mantienes sincronizado con cualquiera más tocando el proyecto. Saltar el pull es la razón más común por la que un push es rechazado.

JunoEnviar y obtener tu trabajogit push origin main envía commits, git pull origin main busca y fusiona, y una vez que una rama tiene una rama ascendente configurada con git push -u, ambos comandos funcionan sin nombrar el remoto o rama nuevamente. Tira antes de enviar en una rama compartida, o tu push es rechazado porque el remoto ya se movió más allá de tu historial local.

JunoEnviar y obtener tu trabajo La rama ascendente que configuras con git push -u se reduce a dos líneas de configuración, branch.<name>.remote y branch.<name>.merge, escritas el momento en que se ejecuta la bandera. git status lee ese mismo par para decirte cuán lejos adelante o atrás está tu rama de origin/main, una comparación que hace enteramente contra tu rama de seguimiento remoto local. Configúralo una vez por rama y cada push o pull abreviado, y cada conteo adelante-atrás, viene gratis.

git fetch vs git pull

git pull hace dos cosas en un paso: descarga lo que cambió en el remoto, luego inmediatamente fusiona esos cambios en la rama en la que estás. git fetch hace solo la primera mitad. Descarga nuevos commits pero nunca los fusiona en tu rama. Tu rama actual, y tus archivos de trabajo, permanecen exactamente donde estaban hasta que le dices a Git que fusione o tire.

Este es el tropiezo que casi todos golpean al menos una vez: ejecuta git fetch, no ve cambio visible en ningún lugar, y asume que nada sucedió en el remoto. Algo sucedió: fetch no ha tocado tu rama de trabajo aún. Para ver qué bajó, mira la rama de seguimiento remoto de antes en este capítulo: git log origin/main muestra commits en el remoto que no han llegado a tu main local. Cuando estés listo para traerlos, git merge origin/main lo hace, o git pull ejecuta fetch y esa fusión para ti en un comando.

Tira del fetch por sí solo cuando quieras mirar antes de fusionar. Digamos que un compañero, Carlos, menciona que empujó 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 aterrice en tu rama de trabajo. Una vez que estés satisfecho, git merge origin/main lo trae. Día a día, la mayoría de las personas van directo a git pull, porque ver y fusionar en un paso es lo que de todos modos quieren. Fetch se justifica en una rama compartida donde preferirías leer el trabajo entrante primero, o antes de que decides si ahora es un buen momento para fusionar en absoluto.

Lo que fetch realmente actualiza está gobernado por un refspec: un mapeo, almacenado en la configuración de tu remoto, que le dice a Git qué ramas en el remoto traer y qué nombres locales almacenarlas bajo. El refspec predeterminado en un clon normal lee aproximadamente como +refs/heads/*:refs/remotes/origin/*, significando "toma cada rama bajo las heads del remoto y espéjala en mis ramas de seguimiento remoto, moviéndolas para que coincidan incluso si eso sobrescribe a lo que solían apuntar." Ese es el mecanismo completo detrás de origin/main manteniéndose actual: fetch lee las ramas del remoto y reescribe tus ramas de seguimiento remoto para que coincidan, luego se detiene. Nada sobre tu propio main cambia hasta que una fusión, rebase, o pull separado actúe en lo que fetch trajo.

Junogit fetch vs git pullgit pull descarga nuevos commits y los fusiona en tu rama en un paso. git fetch solo los descarga y actualiza la memoria de Git de dónde se sitúa el remoto; tu rama se queda donde está hasta que fusiones. Ver no cambio en tus archivos justo después de un fetch es esperado, los nuevos commits 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 paso. Tira del plain fetch cuando quieras leer commits entrantes con git log origin/main antes de que aterricen en tu rama, y pull cuando estés listo para fusionarlos de inmediato. Mezclar los dos es uno de los mix-ups de Git más comunes en un equipo.

Junogit fetch vs git pull Un refspec decide exactamente qué fetch trae y qué ramas de seguimiento remoto actualiza, origin/main incluido, y el predeterminado espeja cada rama bajo las heads del remoto. Fetch solo mueve tus ramas de seguimiento remoto, nunca tu rama revisada, así que fusionar o tirar sigue siendo un paso separado y deliberado.

Dónde esto te deja

Push, pull, y fetch obtienen tus commits en un remoto compartido y de vuelta, que cubre la mayoría de lo que la colaboración día a día en Git requiere. Todo aquí se construye sobre el ciclo de commits: aún etapas y confirmas localmente primero, un remoto solo cambia dónde esos commits pueden viajar. La siguiente pieza es hacer esa colaboración a través de GitHub mismo, proponiendo un cambio y teniéndolo revisado antes de que se fusione. El flujo de solicitud de extracción recoge exactamente allí. Si un término en este capítulo aún se siente inestable, rama de seguimiento remoto, refspec, rama ascendente, el Glosario tiene una definición simple para cada uno, y Qué es Git vale la pena una segunda mirada por la distinción Git-versus-GitHub por sí sola.