Módulo 2: Git desde cero para automatizadores

6. Sube a GitHub: respaldo y trabajo compartido

Siguiente →

Descripción

Al terminar esta lección vas a poder sacar tu repositorio de tu máquina y ponerlo a salvo en internet, donde puede respaldarse y compartirse. Vas a entender qué es un remoto —una copia de tu repositorio alojada en otro lado— y por qué Git es distribuido, vas a crear un repositorio en GitHub, y vas a manejar los cuatro comandos que conectan tu máquina con esa copia: git remote para vincularlos, git push para subir tu historial, git pull para bajar lo que otros suban, y git clone para que alguien más obtenga una copia completa. Y vas a ver por qué GitHub cubre —gratis— eso de "compartir workflows entre usuarios" que la edición Community de n8n no trae de forma nativa.

Esto importa por dos razones que se refuerzan. La primera es de supervivencia: hasta ahora todo tu historial vive en un solo disco, el de tu máquina, y si ese disco falla, se pierde entero. Un remoto es tu respaldo. La segunda es de colaboración: un historial encerrado en tu máquina no le sirve a nadie más. En cuanto está en GitHub, tu compañera puede clonarlo, trabajar en su rama, y devolverte sus cambios. Es el salto de "yo versiono mis workflows" a "mi equipo versiona sus workflows", que es lo que el mercado pide cuando habla de entregar "version-controlled JSON" que otros puedan revisar.

Conexión con el módulo: las lecciones 2 a 5 fueron íntegramente locales —todo pasó en tu máquina, sin internet—. Esta abre la puerta al mundo. Las ramas de la lección 5 cobran aquí su sentido pleno: en un flujo compartido, cada persona trabaja en su rama y las sube a GitHub. Los diffs de la lección 4 son cómo revisas lo que sube un compañero antes de aceptarlo. Y esto conecta directo con el Módulo 1: allí vimos que la edición Community de n8n no incluye source control ni el "compartir entre usuarios" que sí traen las ediciones de pago; GitHub cubre esa carencia sin costo, y el Módulo 6 vuelve sobre esa decisión con honestidad.

Qué es un remoto, y por qué Git es distribuido

Empecemos por una propiedad de Git que lo hace distinto de casi todo lo que conoces. Cuando guardas un documento en Google Docs, la "verdad" del documento vive en los servidores de Google; tu navegador solo muestra una ventana a esa verdad. Git no funciona así. En Git, cada copia del repositorio es completa: tiene todo el historial, todos los commits, todas las ramas. La copia en tu máquina no es una ventana a un original que vive en otro lado; es un original en sí misma.

A eso se le llama que Git es distribuido: no hay un "servidor central" que sea el único dueño de la verdad. Hay copias, todas completas, que se sincronizan entre sí cuando tú se lo pides. Tu máquina tiene una copia. GitHub tiene otra. Tu compañera tendrá una tercera. Las tres tienen el historial entero, y de vez en cuando se ponen de acuerdo.

Un remoto (remote) es, simplemente, otra copia de tu repositorio que vive en un lugar distinto al tuyo, y a la que tu Git sabe cómo conectarse. Lo normal es que ese "lugar distinto" sea un servicio en internet como GitHub, pero conceptualmente un remoto podría ser un disco en otra máquina de tu oficina. Lo que lo hace "remoto" es que no es tu copia local; es una copia con la que sincronizas.

Piénsalo como dos personas con cuadernos idénticos que anotan lo mismo. Tú tienes tu cuaderno (tu repositorio local) y hay otro cuaderno guardado en una caja fuerte (el remoto en GitHub). De vez en cuando abres la caja fuerte y copias en el cuaderno de allí lo que escribiste en el tuyo —eso es git push, empujar tus cambios hacia el remoto—. Y de vez en cuando copias en tu cuaderno lo que otros escribieron en el de la caja —eso es git pull, jalar los cambios del remoto hacia ti—. Los dos cuadernos son completos y válidos por sí solos; la caja fuerte solo agrega seguridad y un punto de encuentro para varias personas.

Esta propiedad tiene una consecuencia práctica muy tranquilizadora: puedes seguir trabajando sin internet. Como tu copia es completa, haces commits, creas ramas, lees diffs y todo el historial estando desconectado. Solo necesitas internet para los dos momentos de sincronización: push (subir) y pull (bajar). Todo lo demás es local.

GitHub: qué es y por qué lo usamos

Un remoto necesita vivir en algún lado. GitHub es un sitio web que aloja repositorios de Git: le das una copia de tu repositorio y él la guarda, la respalda y se la sirve a quien tú autorices. Es, con mucho, el más popular, pero no es el único —existen GitLab, Bitbucket y otros, que hacen lo mismo—. Para esta guía usamos GitHub porque es el estándar del mercado y su plan gratuito alcanza de sobra para lo que necesitamos.

Aquí conviene volver a separar dos nombres que la lección 1 ya distinguió, porque es el momento en que la distinción se vuelve tangible. Git es el programa en tu máquina que lleva el historial; lo has usado en las cuatro lecciones anteriores sin tocar internet. GitHub es el sitio donde alojas una copia de ese historial. No necesitas GitHub para usar Git —lo comprobaste— pero sí necesitas algo como GitHub para respaldar y compartir. Recién ahora, en la lección 6, GitHub entra en escena, y entra porque ya tienes algo que subir.

Vale la pena conectar esto con lo que vimos en el Módulo 1. Allí fuimos honestos sobre una limitación de la edición Community de n8n —la gratuita, la que esta guía toma por defecto—: no incluye control de versiones nativo ni la función de compartir workflows entre usuarios de forma integrada; esas capacidades viven en las ediciones de pago (Enterprise/Cloud). GitHub cubre justamente ese hueco, y sin costo. Con tu workflow en un repositorio de GitHub, tienes control de versiones (el que aprendiste) y un lugar donde otra persona del equipo puede obtener el workflow, proponer cambios y devolvértelos. No es exactamente lo mismo que el source control nativo de n8n —el Módulo 6 compara las dos vías y te da el criterio para decidir cuándo una versión de pago vale la pena—, pero para un equipo pequeño como Cumbre, el flujo repositorio-en-GitHub resuelve el problema a costo cero.

Público y privado: una decisión que importa

Al crear un repositorio en GitHub eliges si es público (cualquiera en internet puede verlo) o privado (solo tú y quienes invites). Para los workflows de una empresa, la respuesta por defecto es clara: privado.

La razón es doble. Primero, un workflow es lógica de negocio de la empresa —cómo Cumbre clasifica y enruta sus pedidos no es algo que quieras publicar—. Segundo, y más delicado: aunque en la lección 3 dijimos que las credenciales nunca deben entrar al repositorio (y el Módulo 3 lo formaliza con la separación de credenciales), el JSON de un workflow puede contener rastros que no conviene exponer —URLs internas, nombres de sistemas, estructuras de datos—. Un repositorio privado te da un margen de seguridad. La regla sencilla: los repositorios de workflows de trabajo van privados salvo que tengas una razón deliberada para hacerlos públicos. Un repositorio de práctica tuyo puede ser público sin problema; el de cumbre-automations con lógica real, privado.

Autenticación: la parte que cambia con el tiempo

Antes de subir nada, un aviso honesto. Para que GitHub te deje empujar cambios a tu repositorio, tiene que estar seguro de que eres tú. Ese paso —la autenticación— es la parte de esta lección que más ha cambiado con los años y la que más probablemente sea distinta cuando leas esto, así que la trato con cuidado y te mando a la fuente oficial para el detalle exacto.

Lo importante de saber: GitHub ya no acepta tu contraseña normal para las operaciones de Git desde la terminal. Dejó de hacerlo en 2021 por seguridad. Hoy hay dos caminos principales, y cualquiera sirve:

  • Token de acceso personal (PAT) sobre HTTPS. Un PAT es como una contraseña especial, larga y revocable, que generas en la configuración de tu cuenta de GitHub y que usas en lugar de tu contraseña cuando Git te la pide. Es el camino más simple para empezar.
  • Llave SSH. Un par de llaves criptográficas —una pública que le das a GitHub y una privada que se queda en tu máquina— que autentican sin escribir nada cada vez. Es más cómodo a largo plazo, pero tiene más pasos de configuración inicial.

En la práctica, en muchos sistemas modernos, la primera vez que hagas git push va a aparecer un asistente —el Git Credential Manager— que te abre el navegador para que inicies sesión en GitHub y guarda la autorización por ti, sin que tengas que generar un PAT a mano. Si eso ocurre, sigue el asistente y listo. Si no, vas a necesitar generar un PAT o configurar una llave SSH siguiendo la guía oficial de GitHub, que está siempre al día y explica cada paso con capturas.

No voy a reproducir aquí los clics exactos porque envejecerían mal: los nombres de los botones y las pantallas de GitHub cambian varias veces al año. Lo que no cambia es el concepto —tienes que probarle a GitHub que eres tú, con un PAT o con SSH— y dónde buscarlo, que está en los recursos al final. Marco este dato con fecha, como todo lo volátil: a julio de 2026, PAT sobre HTTPS y llaves SSH son los dos caminos vigentes, y el asistente en el navegador es lo más común al empezar.

Conectar y subir: remote, push, clone, pull

Con el concepto claro, vamos al flujo completo. Son cuatro comandos.

Ejemplo trabajado: sube cumbre-automations a GitHub

Paso 1 — Crea el repositorio vacío en GitHub. Entra a GitHub (crea una cuenta si no tienes; el plan gratuito basta), y crea un repositorio nuevo. En la pantalla de creación:

  • Ponle de nombre cumbre-automations, igual que tu carpeta local. No es obligatorio que coincidan, pero ayuda a no confundirte.
  • Elige Private (privado), por las razones de más arriba.
  • No marques las opciones de "inicializar con un README", ".gitignore" ni "licencia". Esto es clave: tu repositorio local ya tiene commits, y quieres subir esos. Si GitHub crea el repo con archivos propios, las dos historias chocan y complica el primer push. Créalo completamente vacío.

Al terminar, GitHub te muestra una página con instrucciones y, sobre todo, la URL del repositorio, algo como https://github.com/ana-cumbre/cumbre-automations.git. Esa URL es la dirección de tu remoto. Cópiala.

Paso 2 — Conecta tu repositorio local con el remoto. De vuelta en tu terminal, parado en cumbre-automations, dile a Git dónde vive el remoto:

# git remote add <apodo> <url>: registra un remoto con un apodo.
git remote add origin https://github.com/ana-cumbre/cumbre-automations.git

Qué esperar. El silencio del éxito: nada. Desmenucemos el comando, porque tiene una pieza que confunde:

  • git remote add significa "registra un remoto nuevo".
  • origin es el apodo que le das a este remoto. Por convención universal, el remoto principal se llama origin —no es una palabra mágica, es solo la costumbre, como llamar "casa" a tu dirección principal—. Podrías llamarlo distinto, pero todo el mundo usa origin y conviene seguir la costumbre.
  • La URL es la dirección que copiaste de GitHub.

Confirma que quedó registrado:

git remote -v
origin	https://github.com/ana-cumbre/cumbre-automations.git (fetch)
origin	https://github.com/ana-cumbre/cumbre-automations.git (push)

Aparece dos veces —una para fetch (bajar) y otra para push (subir)— porque Git te deja, en teoría, bajar de un lado y subir a otro; en la práctica son la misma URL. Lo importante es que origin ya apunta a tu repositorio de GitHub.

Paso 3 — Empuja tu historial al remoto. El momento del envío:

# -u vincula tu rama local main con la del remoto, para futuros push.
git push -u origin main

Aquí es donde puede aparecer el paso de autenticación —el asistente del navegador, o la petición de tu PAT—. Resuélvelo según lo que te muestre tu sistema.

Qué esperar una vez autenticado:

Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (12/12), 4.21 KiB | 4.21 MiB/s, done.
Total 12 (delta 3), reused 0
To https://github.com/ana-cumbre/cumbre-automations.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Es más verboso que otros comandos, pero las líneas que importan son las de abajo. * [new branch] main -> main: tu rama main local se creó en el remoto. Y branch 'main' set up to track 'origin/main': tu main local ahora está vinculada con la main del remoto —eso es lo que hizo la -u—, lo que significa que a partir de ahora puedes hacer git push y git pull a secas, sin repetir origin main cada vez. La -u solo se necesita la primera vez por rama.

Lo lograste: tu historial completo está a salvo en GitHub. Si abres la URL de tu repositorio en el navegador, vas a ver tu order-triage.json y, en la pestaña de commits, toda la historia que construiste —Add order-triage workflow, Widen CRM lookup timeout, Add wholesale category—, cada uno con tu nombre y su fecha. Ese es el respaldo y el punto de encuentro que buscábamos.

Paso 4 — El flujo del día a día: push y pull. De aquí en adelante, tu ciclo tiene un paso más. Trabajas local como siempre —editas, add, commit— y cuando quieres respaldar o compartir tu trabajo, lo empujas:

git push

(Sin origin main, porque la -u ya vinculó la rama.) Qué esperar: un resumen parecido al del primer push, pero más corto, terminando en algo como a91c3f8..b2c4d6e main -> main, que te dice qué rango de commits subió.

Y cuando quieres traer lo que otros hayan subido al remoto:

git pull

Qué esperar, si no hay nada nuevo: Already up to date. (ya estás al día). Si sí hay cambios de otra persona, Git los baja y los fusiona con tu trabajo, mostrándote un resumen del tipo de los diffs que ya sabes leer. pull es, en el fondo, "baja lo nuevo del remoto y fusiónalo con lo mío" —por eso, cuando hay cambios en conflicto, puede pedirte que resuelvas un conflicto de fusión, exactamente como viste en la lección 5—.

Cómo obtiene el workflow tu compañera: git clone

El otro lado de la colaboración. Cuando alguien nuevo del equipo necesita el repositorio —o cuando tú lo necesitas en otra máquina— no se crea desde cero: se clona. Clonar es descargar una copia completa del repositorio desde el remoto, con todo su historial y todas sus ramas.

Tu compañera, en su máquina, corre:

# git clone <url>: descarga una copia completa del repositorio.
git clone https://github.com/ana-cumbre/cumbre-automations.git

Qué esperar:

Cloning into 'cumbre-automations'...
remote: Enumerating objects: 12, done.
remote: Total 12 (delta 3), reused 12
Receiving objects: 100% (12/12), 4.21 KiB | 4.21 MiB/s, done.
Resolving deltas: 100% (3/3), done.

Git crea una carpeta cumbre-automations con el order-triage.json dentro y todo el historial en su .git. Fíjate en lo que no hizo falta: ella no corrió git init, ni git remote add —clonar configura el remoto origin automáticamente apuntando a la URL de donde clonó—. A partir de ese momento, ella tiene una copia completa e independiente: puede crear ramas, hacer commits, y cuando quiera compartir, git push (si le diste permiso de escritura en el repositorio) o proponerte los cambios. Es la copia distribuida de la que hablábamos: completa, válida por sí sola, sincronizable con la tuya a través del remoto común.

El flujo compartido, en una imagen

Juntando todo, así se ve el trabajo de dos personas sobre order-triage a través de GitHub:

  1. Tú creas el repositorio y haces el primer git push. El remoto ahora tiene la historia.
  2. Tu compañera hace git clone. Ahora los dos tienen copias completas.
  3. Cada quien trabaja en su rama (lección 5): tú en add-priority-routing, ella en fix-crm-timeout. Cada quien hace git push de su rama al remoto.
  4. Antes de fusionar, revisan los cambios del otro con los diffs de la lección 4 —GitHub además los muestra visualmente en su web—.
  5. Las ramas buenas se fusionan a main y se hace git push de main. El otro hace git pull para traer esa main actualizada a su copia.

Ese ir y venir —push para dar, pull para recibir, cada quien en su rama— es el latido del trabajo compartido. No hay un jefe central que "tiene el archivo bueno"; hay un remoto común que todos sincronizan, y main en ese remoto es la versión de la verdad que el equipo acuerda. Para Cumbre, eso es exactamente el "compartir workflows entre usuarios" que la edición Community no traía, resuelto con herramientas gratuitas.

GitHub no es solo un respaldo: también es un visor

Vale la pena saber que GitHub no guarda tu historia en silencio; te la muestra. Todo lo que aprendiste a leer en la terminal, GitHub lo presenta en su página web de forma visual, y para muchas revisiones es más cómodo.

En la página de tu repositorio puedes navegar el historial de commits con un clic, y al abrir cualquier commit, GitHub te muestra su diff —el mismo que verías con git diff, con las líneas quitadas en rojo y las agregadas en verde, pero coloreado y con mejor formato—. Es una forma agradable de revisar qué cambió sin salir del navegador. Las cuatro reglas de leer a través del ruido de la lección 4 valen igual aquí: en un JSON de n8n sin normalizar, GitHub también te va a mostrar el ruido de versionId y posiciones mezclado con el cambio real.

Hay una función que conviene mencionar aunque no la vayamos a desarrollar: los Pull Requests (solicitudes de fusión). Un Pull Request es la forma que tiene GitHub de proponer fusionar una rama en otra —por ejemplo, tu rama add-priority-routing en main— deteniéndose a revisar antes de fusionar. Muestra el diff completo de todo lo que trae la rama, deja que un compañero lo comente línea por línea y lo apruebe, y solo entonces se fusiona. Es el mecanismo estándar con el que los equipos revisan cambios antes de que entren a main, y es exactamente donde tu habilidad de leer diffs se vuelve dinero: revisar el Pull Request de otra persona es leer su diff y decidir si el cambio entra.

No vamos a montar el flujo de Pull Requests aquí —el trabajo de revisión en equipo se profundiza en el Módulo 6, incluida la revisión de cambios generados con IA—. Por ahora quédate con que existe, con que se apoya en las ramas de la lección 5 y en los diffs de la lección 4, y con que es la razón por la que subir tu trabajo a GitHub no es solo respaldarlo: es habilitar que alguien más lo revise antes de aceptarlo.

Un aviso de expectativa, para no frustrarte cuando lo veas: en un JSON de n8n sin normalizar, la vista de diff de GitHub —igual que la de tu terminal— va a mezclar el cambio real con el ruido de versionId y posiciones, y en un archivo minificado de una sola línea será tan poco útil como en la terminal. GitHub no hace magia sobre el formato del archivo; solo lo presenta más bonito. La solución de fondo sigue siendo la misma que anunciamos en la lección 4: normalizar el JSON, que es el Módulo 3. Con diffs limpios, la vista de GitHub y los Pull Requests se vuelven una herramienta de revisión de verdad cómoda.

Errores comunes

Inicializar el repositorio de GitHub con archivos y chocar en el primer push (práctico). Qué pasa: al crear el repo en GitHub marcas "Add a README" (o un .gitignore, o una licencia), y cuando intentas git push desde tu repositorio local —que ya tiene commits— Git te rechaza el envío con un mensaje sobre historias que no coinciden ("rejected", "failed to push some refs", "fetch first"). Por qué pasa: GitHub creó un commit propio (el del README) que tu historia local no conoce, así que las dos líneas divergieron desde el inicio y Git no quiere pisar una con la otra. Cómo detectarlo: si tu primer push falla mencionando "rejected" o "fetch first" y tú no habías subido nada antes, es esto. Cómo corregirlo: lo más limpio es crear el repositorio de GitHub vacío, sin ninguna casilla marcada, cuando ya tienes historia local que subir. Si ya lo creaste con archivos, la salida es hacer primero git pull origin main para traer el commit del README y fusionarlo, y luego sí git push.

Intentar autenticarte con tu contraseña de GitHub (práctico). Qué pasa: haces git push, Git te pide usuario y contraseña, escribes tu contraseña normal de GitHub, y falla con un error de autenticación. Por qué pasa: GitHub dejó de aceptar la contraseña de la cuenta para operaciones de Git en 2021; ahora hay que usar un PAT o SSH. Cómo detectarlo: si el push falla justo tras escribir tu contraseña, con un mensaje sobre autenticación o "support for password authentication was removed", es esto. Cómo corregirlo: usa el asistente del navegador si aparece, o genera un token de acceso personal (PAT) en la configuración de GitHub y úsalo en lugar de la contraseña cuando Git te la pida, o configura una llave SSH. La guía oficial de GitHub (en los recursos) tiene el paso a paso actualizado.

Subir un repositorio con secretos, o dejarlo público (práctico y serio). Qué pasa: se sube a GitHub un repositorio que contenía un archivo de credenciales, o se crea el repo como público cuando tenía lógica de negocio o rastros sensibles. Por qué pasa: la prisa por "subir todo" se lleva por delante la revisión, y la opción de público a veces está preseleccionada. Cómo detectarlo: antes de tu primer push, revisa con git status y git log qué archivos están versionados; si ves .env, credentials.json o similares, hay un problema. Cómo corregirlo: previénelo —el .gitignore de la lección 3 debe excluir los secretos antes del primer commit, y el repositorio de trabajo va privado por defecto—. Si ya subiste un secreto, cambiar la visibilidad a privado no basta: el secreto quedó en el historial y hay que rotarlo (invalidarlo y generar uno nuevo) y limpiarlo del historial, un tema serio que el Módulo 3 trata. La regla: piensa en secretos y visibilidad antes de empujar, no después.

Push rechazado porque el remoto tiene cambios que tú no (práctico). Qué pasa: haces git push y Git lo rechaza diciendo algo como "Updates were rejected because the remote contains work that you do not have locally" y sugiere git pull. Por qué pasa: alguien más (o tú desde otra máquina) subió commits al remoto que tu copia local no tiene, así que empujar los tuyos encima borraría los suyos —Git no lo permite—. Cómo detectarlo: el mensaje de rechazo menciona "fetch first" o "remote contains work". Cómo corregirlo: haz git pull primero para traer y fusionar los cambios del remoto con los tuyos —resolviendo un conflicto si aparece, como en la lección 5— y luego git push. Es el ritmo normal del trabajo compartido: bajar antes de subir. Adoptar el hábito de git pull antes de empezar a trabajar cada día previene la mayoría de estos rechazos.

Ejercicios

Ejercicio 1 — Sube tu repositorio de principio a fin. Crea una cuenta de GitHub si no la tienes, crea un repositorio vacío y privado llamado cumbre-automations, conéctalo a tu repositorio local con git remote add origin <url>, verifica con git remote -v, y sube tu historia con git push -u origin main. Confirma abriendo la URL en el navegador que ves tu order-triage.json y la lista de commits.

Ver solución

La secuencia de comandos:

git remote add origin https://github.com/TU-USUARIO/cumbre-automations.git
git remote -v
git push -u origin main

(Reemplazando la URL por la tuya, y resolviendo la autenticación cuando aparezca.)

La verificación real no es que los comandos no den error, sino abrir la página del repositorio en GitHub y ver tu historia ahí. Deberías reconocer cada commit que hiciste en las lecciones anteriores, con su nota y tu nombre. Ver tu propio historial reflejado en la web es el momento en que "respaldé mi trabajo" deja de ser una idea abstracta.

Por qué funciona: este ejercicio junta los tres pasos —crear el remoto vacío, vincularlo, empujar— que son la única parte con truco de toda la colaboración. Una vez que tu historia está en GitHub, el resto (push, pull) es rutina. El detalle que más gente olvida es crear el repo vacío; si lo hiciste bien, tu primer push no dio problemas de historias que chocan.

Ejercicio 2 — Simula un compañero con un clon. En una carpeta distinta de tu máquina (por ejemplo, una carpeta de práctica), clona tu propio repositorio con git clone <url>. Entra a la carpeta clonada, corre git log --oneline y confirma que tiene toda la historia. Luego corre git remote -v en el clon y observa qué remoto quedó configurado sin que tú lo agregaras.

Ver solución

Tras git clone <url> y entrar a la carpeta clonada, git log --oneline muestra exactamente la misma historia que tu repositorio original: los mismos commits, con los mismos folios. Es una copia completa, no un resumen.

Y git remote -v en el clon muestra que origin ya está configurado apuntando a la URL de la que clonaste, sin que tú corrieras git remote add. Eso es lo que quería que vieras: clonar hace por ti la conexión con el remoto. Tu compañera, al clonar, obtiene un repositorio listo para hacer push y pull sin configurar nada.

Por qué funciona: clonar tu propio repo en otra carpeta es la forma más segura de entender qué recibe alguien que colabora contigo: todo el historial, más la conexión al remoto ya hecha. También es, de paso, una técnica real: si quieres tu repositorio en una segunda máquina, no lo copias a mano —lo clonas—.

Ejercicio 3 — Razona el flujo de dos personas. Tú y una compañera trabajan sobre order-triage a través de GitHub. Ordena estos pasos en la secuencia correcta y di, en cada push/pull, qué viaja y hacia dónde: (a) ella hace git pull, (b) tú haces git push de tu rama fusionada a main, (c) ella hace git clone, (d) tú fusionas tu rama a main local, (e) tú haces el primer git push del repositorio, (f) ella crea su rama y trabaja.

Ver solución

Una secuencia correcta: (e) → (c) → (f) → (d) → (b) → (a).

  • (e) Tú haces el primer git push: tu historia local sube al remoto. Ahora GitHub tiene el repositorio.
  • (c) Ella hace git clone: la historia completa baja del remoto a su máquina. Ya tiene su copia.
  • (f) Ella crea su rama y trabaja: todo local en su máquina, sin viajar nada todavía.
  • (d) Tú fusionas tu rama a main local: también local en tu máquina.
  • (b) Tú haces git push de main: tu main actualizada sube al remoto.
  • (a) Ella hace git pull: tu main nueva baja del remoto a su copia, y se fusiona con lo suyo.

Por qué funciona: el patrón que emerge es "push sube, pull baja, y el remoto es el intermediario". Nada viaja directo de tu máquina a la de ella; todo pasa por el remoto común. Entender que no hay conexión directa entre las dos máquinas —solo entre cada una y GitHub— es lo que hace que el trabajo compartido deje de parecer mágico y se vuelva predecible.

Resumen y siguiente paso

En esta lección sacaste tu repositorio de tu máquina y lo pusiste a salvo en GitHub. Entendiste qué es un remoto —otra copia completa de tu repositorio, con la que sincronizas— y por qué Git es distribuido: cada copia tiene el historial entero, así que trabajas sin internet y solo te conectas para push (subir) y pull (bajar). Viste que GitHub aloja esa copia y que cubre, gratis, el "compartir workflows entre usuarios" que la edición Community de n8n no trae, y por qué los repositorios de trabajo van privados. Enfrentaste con honestidad la autenticación —que GitHub ya no acepta tu contraseña y hay que usar un PAT o SSH, un detalle volátil que conviene confirmar en la fuente oficial—. Y recorriste el flujo completo: git remote add origin para vincular, git push -u origin main para el primer envío, git push y git pull para el día a día, y git clone para que un compañero obtenga su copia. Cerraste con la imagen del trabajo de dos personas: cada quien en su rama, todo pasando por el remoto común.

Antes de avanzar a la lección 7 deberías poder: crear un repositorio vacío en GitHub y subir tu historia local; explicar la diferencia entre push, pull y clone; y entender por qué un push puede ser rechazado y qué hacer entonces.

Ya tienes tu workflow versionado, ramificado y respaldado en la nube. Solo falta cerrar el círculo con la razón por la que todo esto vale la pena el día que algo sale mal: poder volver atrás. En la lección 7 vas a aprender a recuperar una versión que funcionaba. Vas a ver la diferencia entre git revert —deshacer un cambio dejando constancia, la vía segura y auditable— y git reset —mover el historial hacia atrás, potente y peligrosa—, cuándo usar cada una y por qué, y a recuperar la versión anterior de un solo archivo con git checkout <commit> -- archivo. Es la lección que convierte todo el historial que construiste en una red de seguridad real: la diferencia entre el "martes malo" de Cumbre resuelto en diez minutos y el resuelto a medianoche entre adivinanzas.

Recursos

← Anterior5. Ramas para cambiar sin miedoSiguiente →7. Rollback: volver a una versión que funcionaba