1. Introducción: Git aplicado a workflows

Descripción

Al terminar esta lección vas a poder explicar por qué Git —y no una carpeta con copias, ni Dropbox, ni el botón de guardar de n8n— es la herramienta correcta para llevar el historial de un workflow, vas a tener claro qué NO vamos a asumir (empezamos desde cero, sin una sola línea de Git previo) y vas a conocer el hilo completo que atraviesa las ocho lecciones de este módulo: un mismo workflow de Cumbre, order-triage, que vas a poner bajo control de versiones paso a paso, desde tu primer git init hasta subirlo a un remoto compartido en GitHub y recuperar una versión que funcionaba.

Esto importa por una razón muy concreta y muy poco romántica: el mercado. Cuando revisas las mejores ofertas de trabajo que mencionan n8n, una parte de ellas pide, con estas palabras exactas, entregar los workflows "as version-controlled, documented JSON" —como JSON versionado y documentado—. No dice "que sepas armar workflows"; eso lo dan por hecho. Dice que sepas tratarlos como un activo del que se lleva historial, que se revisa, que se puede regresar a un estado anterior sin drama. Esa frase es, palabra por palabra, la frontera entre el constructor de workflows y el dueño del sistema de automatización que vimos en el Módulo 1. Y del otro lado de esa frontera, la herramienta que el mercado da por sentada se llama Git.

Conexión con el módulo: esta lección es el mapa, no el terreno. Todavía no vas a escribir un solo comando de Git en tu máquina; aquí defines el problema (por qué el historial improvisado no alcanza), conoces la herramienta a vista de pájaro y recibes el plan de las siete lecciones que siguen. La lección 2 te instala Git y crea tu primer repositorio. Las lecciones 3 a 5 son el corazón del ciclo diario: hacer commits, leer diffs y trabajar en ramas. Las lecciones 6 y 7 cierran con el respaldo compartido en GitHub y la recuperación de versiones anteriores. Y la lección 8 junta todo en un proyecto: order-triage con historial legible, iterado en varias ramas y con un cambio revertido de forma limpia. Una nota de límite desde ya, porque enseñar de más confunde tanto como enseñar de menos: aquí no vas a ver rebase interactivo, ni submódulos, ni las estrategias de branching de un equipo de cincuenta personas. Solo el Git que necesita el ciclo de vida de un workflow. Ni un comando más.

El problema real: order-triage-final-final-v2-OK.json

Déjame describirte una escena que probablemente ya viviste, aunque sea con otro tipo de archivo.

Tienes un workflow que funciona. Lo exportas "por si acaso" y lo guardas como order-triage.json. La semana siguiente le haces un cambio, y como no quieres perder el que ya servía, guardas el nuevo como order-triage-v2.json. Un mes después hay order-triage-v2-priority.json, order-triage-BUENO.json, order-triage-final.json y —el clásico— order-triage-final-final-v2-OK.json. Alguien del equipo tiene su propia carpeta con su propia versión. Y el día que producción se rompe y alguien pregunta "¿cuál era el que funcionaba el martes pasado?", nadie sabe la respuesta con certeza. Abren tres archivos, los comparan a ojo, y adivinan.

Ese caos tiene nombre técnico: falta de control de versiones. Y la parte incómoda es que casi todos lo resolvemos mal de la misma forma —con copias fechadas a mano— porque parece lo natural. El problema es que ese método falla justo cuando más lo necesitas: no te dice qué cambió entre una versión y otra, no te dice quién lo cambió ni por qué, no te deja trabajar en algo nuevo sin arriesgar lo que ya sirve, y cuando hay que volver atrás, volver atrás significa "abrir archivos viejos y rezar".

Piénsalo como la diferencia entre un cajón lleno de fotos sueltas y un álbum. En el cajón tienes las fotos, sí, pero no sabes de qué día es cada una, en qué orden pasaron las cosas, ni cuál viene después de cuál. El álbum tiene las mismas fotos, pero cada una con su fecha, en orden, con una nota de qué estaba pasando. Git es el álbum. Cada versión de tu workflow queda con su fecha, su autor, una nota de qué cambió y su lugar exacto en la línea del tiempo.

Por qué Git y no Dropbox, Google Drive o el historial de n8n

Es una pregunta justa, porque esas herramientas también "guardan versiones". Vale la pena ser honestos sobre qué hace cada una y por qué ninguna sustituye a Git para esto.

Dropbox y Google Drive guardan versiones automáticamente, es cierto. Pero guardan versiones de un archivo entero, no de un cambio con intención. No te dejan decir "estas cinco modificaciones van juntas porque resuelven el mismo problema, y esta nota explica por qué". No te dejan trabajar en dos ideas distintas al mismo tiempo sin que se pisen. Y su comparación entre versiones, cuando existe, no está pensada para leer el cambio real dentro de un archivo de texto estructurado como el JSON de un workflow. Son excelentes para respaldar; son pobres para entender la evolución de algo.

El historial de ejecuciones y de versiones de n8n es útil dentro de la plataforma, y en las ediciones de pago hay control de versiones nativo del que hablamos con honestidad en el Módulo 6. Pero en la edición Community —el punto de partida por defecto de esta guía, a costo cero— ese historial vive atado a la instancia. Si la instancia se corrompe, si migras de servidor, si quieres el historial fuera de n8n para revisarlo, compartirlo o meterlo en un proceso de revisión de equipo, necesitas algo que sea independiente de la plataforma. Git es exactamente eso: el historial vive en una carpeta que es tuya, que puedes copiar, mover y respaldar donde quieras.

Git, en cambio, fue diseñado desde el primer día para una sola cosa: llevar el historial de archivos de texto de forma que puedas ver qué cambió línea por línea, agrupar cambios con una explicación, trabajar en paralelo sin miedo, y volver a cualquier punto anterior con precisión quirúrgica. Un workflow de n8n exportado es un archivo de texto —JSON—. Encaja en Git como anillo al dedo. Con una salvedad importante que vamos a enfrentar de cara en la lección 4, y que el Módulo 3 termina de resolver: ese JSON, tal como sale de n8n, no es el archivo de texto más amable del mundo para Git. Pero eso tiene arreglo, y el arreglo es parte de lo que aprendes aquí.

Una aclaración que evita una confusión clásica desde ahora: Git no es GitHub. Git es el programa que corre en tu máquina y lleva el historial. GitHub es un sitio web donde puedes alojar una copia de ese historial para respaldarlo y compartirlo. Puedes usar Git durante años sin tocar GitHub jamás. Vamos a usar Git desde la lección 2, y GitHub aparece hasta la lección 6, cuando ya tenga sentido. Si alguna vez oíste "sube tu código a Git" y te confundiste, era esto: la gente mezcla los dos nombres todo el tiempo, y ahora tú ya no vas a hacerlo.

Ejemplo trabajado: cómo se ve el destino

Antes de instalar nada, vale la pena mirar hacia dónde vamos. Esto es lo que vas a poder producir al terminar el módulo: el historial de order-triage visto con un comando de Git que muestra la lista de versiones, una por línea. No lo corras todavía —no tienes Git configurado ni el repositorio creado—; léelo como se lee la foto de la caja de un mueble antes de armarlo.

# El comando que muestra el historial resumido, una versión por línea.
git log --oneline

Qué esperar cuando llegues a la lección 8 y corras eso sobre tu repositorio de Cumbre:

d4f9a1c Revert "Point CRM lookup at the staging URL"
7b2e105 Point CRM lookup at the staging URL
a91c3f8 Add wholesale category to the order classifier
3e5d720 Widen CRM lookup timeout to 15 seconds
c08b4a2 Add order-triage workflow

Detente un segundo en lo que estás viendo, porque este bloque contiene, en miniatura, todo lo que enseña el módulo.

Cada línea es una versión guardada del workflow —en Git se llama commit, y es el concepto de la lección 3—. Se leen de abajo hacia arriba, de la más vieja a la más nueva. La de abajo, c08b4a2 Add order-triage workflow, es el primer día: el momento en que order-triage entró a Git. Las de arriba son cambios posteriores: se amplió el tiempo de espera de la consulta al CRM, se agregó una categoría "wholesale" al clasificador de pedidos, se apuntó la consulta del CRM a una URL de pruebas.

El código raro al principio de cada línea —c08b4a2, 3e5d720— es el identificador único de esa versión. Piénsalo como el número de folio de un documento: no se repite jamás, y con él puedes referirte a exactamente esa versión sin ambigüedad. Los tuyos van a ser distintos de estos; Git los genera, no los eliges tú.

Y fíjate en la última línea, la de más arriba: Revert "Point CRM lookup at the staging URL". Alguien apuntó la consulta del CRM a la URL de pruebas —seguramente por error, o para probar algo— y después lo deshizo de forma limpia y registrada. No borró nada, no abrió un archivo viejo: dejó constancia de que ese cambio se revirtió, con fecha y autor. Eso es la lección 7, y es la diferencia entre "tenía un JSON viejo por ahí" y una recuperación auditable.

Todo el módulo es aprender a producir y a leer ese bloque de texto. Nada más, y nada menos.

El hilo del módulo: order-triage de Cumbre

Como en toda la guía, trabajamos sobre la misma empresa inventada para no gastar energía reaprendiendo el contexto en cada lección. Si vienes del Módulo 1 ya la conoces; si llegaste directo aquí, este es el resumen que necesitas.

Cumbre es una distribuidora mayorista latinoamericana de café y té. Le vende a cafeterías y tiendas pequeñas, y como es un equipo chico, automatiza para no procesar los pedidos a mano. El workflow con el que vamos a trabajar todo el módulo se llama order-triage, y hace tres cosas:

1. Recibe los pedidos que entran, a través de un nodo Webhook.
2. Los clasifica con un nodo AI Agent, que lee el pedido y decide en qué categoría cae —por ejemplo standard, priority o wholesale—.
3. Consulta el CRM por HTTP, con un nodo HTTP Request, para traer los datos del cliente y decidir cómo enrutar el pedido.

No vas a construir order-triage en este módulo —construir workflows es el tema de otras guías del ecosistema, y aquí se asume que ya sabes hacerlo—. Vas a hacer algo distinto y, para el mercado, más valioso: vas a ponerlo bajo control de versiones. En el Módulo 1 lo exportaste como un archivo JSON; en este módulo ese archivo va a vivir dentro de una carpeta que se llama cumbre-automations, y esa carpeta va a convertirse en un repositorio de Git.

Este es el arco completo, lección por lección, para que veas que no son ocho temas sueltos sino un solo movimiento:

Lección	Qué le pasa a order-triage
2	Instalas Git y conviertes la carpeta cumbre-automations en un repositorio. El workflow todavía no tiene historial, pero ya tiene dónde tenerlo.
3	Haces la primera "foto" del workflow: tu primer commit. Y aprendes a hacer fotos limpias, con buenas notas.
4	Cambias algo en order-triage, lo exportas de nuevo, y aprendes a leer qué cambió comparando las dos versiones.
5	Pruebas una idea nueva —una categoría de clasificación adicional— en una rama aparte, sin arriesgar la versión que funciona.
6	Subes todo el historial a GitHub, para respaldarlo y para que otra persona del equipo pueda trabajar sobre él.
7	Un cambio rompió el workflow. Vuelves a la versión que funcionaba, de forma registrada y sin drama.
8	El proyecto: juntas todo lo anterior en un repositorio entregable, con historial legible y un cambio revertido con limpieza.

Si te fijas, es la vida completa de un cambio en un workflow profesional: se guarda, se compara, se experimenta aparte, se comparte, y —cuando algo sale mal— se revierte. Eso es lo que hace un dueño de sistema de automatización, y eso es lo que vas a saber hacer al cerrar el Módulo 2.

Dos martes en Cumbre: el costo real de no versionar

Los argumentos abstractos convencen poco. Veamos el mismo problema en dos versiones de Cumbre: una sin Git y una con Git. La situación es idéntica en las dos, y es de las que pasan de verdad un martes cualquiera.

El disparador. Alguien —tú, o una compañera del equipo— toca order-triage para "mejorar" algo. Cambia la categoría del clasificador, ajusta la URL del CRM, o mueve dos nodos. Guarda, publica, y se va a comer. A las tres de la tarde los pedidos del canal mayorista dejan de enrutarse: caen todos como standard y el equipo de bodega no ve las prioridades. Algo del cambio de la mañana lo rompió.

Cumbre sin Git. El workflow que corre en producción es el único que existe; el "de antes" quedó, en el mejor de los casos, en un archivo order-triage-backup.json que alguien guardó hace tres semanas —o no lo guardó nadie—. Empieza la arqueología: ¿qué se cambió hoy exactamente? Nadie está seguro. Se abre el editor, se mira el workflow y se intenta recordar cómo estaba en la mañana. Se prueban tres cosas al tanteo. Una de ellas parece arreglarlo, pero nadie sabe si arregló la causa o si tapó el síntoma, y como en el proceso se tocaron otros nodos, ahora hay dos cambios sin registrar encima del que rompió. Si el backup de hace tres semanas existe, volver a él significa perder también las mejoras buenas de esas tres semanas. La incidencia se cierra en la noche, con un workflow que "parece funcionar" y una sensación fea de no saber por qué se rompió ni por qué se arregló.

Cumbre con Git. El cambio de la mañana es un commit, con su nota y su autor. Cuando los pedidos mayoristas dejan de enrutarse, el primer comando cuenta la historia: git log muestra que hoy a las 9:40 alguien hizo Point CRM lookup at the staging URL, y que antes de eso el workflow llevaba dos semanas estable. git diff entre la versión de ayer y la de hoy muestra, en tres líneas, exactamente qué cambió: la URL del CRM ahora apunta al servidor de pruebas, que no tiene los datos de los clientes mayoristas. En treinta segundos se sabe la causa. Se revierte ese commit —solo ese— con git revert, y el workflow vuelve al estado que servía, sin perder ninguna de las mejoras buenas de las semanas anteriores, y dejando registro de que ese cambio se deshizo y por qué. La incidencia se cierra en diez minutos, y el equipo aprende algo concreto de ella en lugar de quedarse con un misterio.

La diferencia entre los dos martes no es que un equipo sea más inteligente que el otro. Es que uno tiene el álbum con las fechas y las notas, y el otro tiene el cajón de fotos sueltas. Con las mismas personas, las mismas manos y el mismo error, el desenlace cambia por completo según haya o no un historial que se pueda interrogar.

Y hay un segundo costo, más silencioso, que el martes malo esconde: el miedo a tocar. En Cumbre sin Git, después de un susto así, la gente deja de mejorar el workflow por temor a romperlo de nuevo sin poder volver atrás. El sistema se congela. En Cumbre con Git, como cualquier cambio se puede revertir con precisión, la gente experimenta con tranquilidad —en ramas, como verás en la lección 5— y el workflow sigue evolucionando. El control de versiones no solo te salva de los errores: te devuelve la libertad de mejorar sin miedo. Ese es, al final, el regalo más grande de este módulo.

Qué asumimos y qué no

Vale la pena ser explícitos, porque el miedo más común al llegar a Git es "esto es para programadores de verdad, no para mí".

No asumimos que sabes Git. Ni un comando. Ni sabes qué es un commit, ni una rama, ni un repositorio. Todo eso se define desde cero, con analogías, antes de usarlo. Si en algún momento un término suena a jerga, es un error de esta guía, no una falla tuya.

No asumimos que eres programador. Llegaste a n8n por la automatización, no por la programación, y está perfectamente bien. Git no es programar: es llevar el historial de archivos. Un escritor, un diseñador o un abogado podrían usar Git para sus documentos con el mismo provecho. Da la casualidad de que quien mejor lo aprovecha son quienes trabajan con archivos de texto que cambian con el tiempo, y un workflow exportado es exactamente eso.

Sí asumimos tres cosas mínimas, todas del terreno que ya pisaste: que construiste workflows reales en n8n y te sientes cómodo con el editor 2.0; que sabes exportar un workflow a JSON (lo hiciste en el Módulo 1); y que puedes abrir una terminal en tu máquina y escribir un comando. Si esto último te pone nervioso, tranquilo: la lección 2 empieza justo ahí, con la terminal más básica, y no vas a necesitar nada más avanzado que escribir un comando y leer lo que responde.

Una promesa que vale la pena hacer temprano: al terminar este módulo no vas a "saber Git" en el sentido de dominar sus doscientos comandos —nadie los domina, ni los expertos—. Vas a saber los ocho o nueve que se usan el 95% del tiempo para llevar el historial de un workflow, y los vas a saber bien, entendiendo qué hace cada uno por dentro. Eso es más que suficiente para cruzar la frontera al lado profesional, y es más de lo que muchos que se dicen "usuarios de Git" realmente entienden.

Un vistazo al vocabulario que viene

No vamos a definir nada a fondo todavía —cada término tiene su lección—, pero conviene que las palabras no te tomen por sorpresa cuando aparezcan. Piensa en esta lista como el índice de personajes al principio de una novela: no tienes que memorizarlo, solo saber que existe para volver a él.

• Repositorio (repo): la carpeta de tu proyecto una vez que Git le está llevando el historial. Lección 2.
• Commit: una foto guardada del proyecto en un momento dado, con nota, fecha y autor. Lección 3.
• Staging (área de preparación): el lugar donde eliges qué va a salir en la próxima foto, antes de tomarla. Lección 3.
• Diff: la comparación que te muestra qué cambió entre dos versiones, línea por línea. Lección 4.
• Rama (branch): una línea de trabajo paralela donde puedes experimentar sin tocar la versión buena. Lección 5.
• Merge (fusión): el acto de traer los cambios de una rama de vuelta a la principal. Lección 5.
• Remoto (remote): una copia de tu repositorio alojada en otro lado, como GitHub, para respaldo y trabajo compartido. Lección 6.
• Revert / rollback: deshacer un cambio y volver a una versión anterior de forma registrada. Lección 7.

Ocho palabras. Ese es, casi entero, el vocabulario que separa a quien versiona sus workflows de quien los guarda como final-final-v2. No es tanto.

Sobre la terminal negra, antes de que te asuste

Desde la lección 2 vas a escribir comandos de Git en una terminal —esa ventana de fondo oscuro donde tecleas y la máquina responde con texto—. Para mucha gente que llegó a la automatización por el lienzo visual de n8n, esa ventana produce un rechazo casi físico: se ve intimidante, se ve "de hackers", se ve como el lugar donde un comando mal escrito borra tu disco duro. Vale la pena desactivar ese miedo ahora, porque es infundado y te va a estorbar.

La terminal es, simplemente, una forma de darle órdenes a la máquina escribiendo en vez de haciendo clic. Nada más. Cuando escribes git status y presionas Enter, le estás preguntando a Git "¿cómo está mi proyecto?", igual que cuando haces clic en un botón que dice "Estado". La única diferencia es que en vez de un botón, escribes una palabra. Y los comandos de Git que vas a usar son órdenes de leer y de guardar, no de destruir: git status, git log, git diff solo miran y no cambian nada; git add y git commit guardan; los pocos comandos que sí pueden borrar trabajo —los verás en la lección 7— vienen con su advertencia grande y su alternativa segura.

Piénsalo como aprender a pedir un café en otro idioma. La primera vez, decir "un café con leche, por favor" en un idioma nuevo da nervios y sale entrecortado. A la décima vez lo dices sin pensar. Los comandos de Git son ese puñado de frases: al principio los copias con cuidado, y en dos semanas los escribes de memoria sin darte cuenta. No hay que entender la gramática entera del idioma para pedir el café. No hay que "saber la terminal" para usar Git.

Un hábito que te va a servir toda la vida y que empieza aquí: cuando un comando te devuelva un texto que no entiendes, no lo ignores ni entres en pánico. Léelo. Git es sorprendentemente conversador: cuando algo sale mal, casi siempre te dice qué pasó y hasta te sugiere el comando para arreglarlo. Vas a ver ejemplos de eso en cada lección. La terminal no es tu enemiga; es la interlocutora más honesta que vas a tener.

Errores comunes

Creer que Git es solo para programadores (conceptual). Qué pasa: alguien mira Git, ve comandos en una terminal negra y concluye "esto no es para mí, yo hago automatización sin código". Por qué pasa: Git nació en el mundo del desarrollo de software y casi todo su material está escrito para programadores, con ejemplos de código en lenguajes que un automatizador no usa. Esa presentación crea la ilusión de que hay un prerrequisito de programación que en realidad no existe. Cómo detectarlo: si tu razón para no usar Git es "no sé programar" y no "no lo necesito", es esta confusión. Cómo corregirlo: recuerda qué hace Git en realidad —lleva el historial de archivos de texto— y que un workflow exportado es un archivo de texto. No hay que escribir código para versionar un archivo; hay que aprender ocho comandos, que es lo que hace este módulo. La barrera es de presentación, no de dificultad.

Confundir Git con GitHub (conceptual). Qué pasa: se usan los dos nombres como sinónimos —"sube esto a Git", "mi código está en Git"— y después vienen malentendidos sobre qué se necesita para empezar. Por qué pasa: la mayoría de la gente conoce Git a través de GitHub, así que asocia los dos nombres como si fueran uno. Cómo detectarlo: si crees que necesitas una cuenta en algún sitio web para empezar a versionar, tienes los conceptos mezclados. Cómo corregirlo: quédate con la separación —Git es el programa local que lleva el historial; GitHub es un sitio opcional donde alojar una copia—. Vas a usar Git a solas en tu máquina durante cuatro lecciones antes de que GitHub aparezca siquiera. No necesitas cuenta de nada para la lección 2.

Pensar que exportar e importar JSON ya es "versionar" (conceptual). Qué pasa: alguien exporta su workflow cada tanto, guarda el archivo con la fecha en el nombre, y cree que con eso ya tiene control de versiones. Por qué pasa: la copia fechada a mano se parece lo suficiente al versionado como para dar una falsa sensación de seguridad; efectivamente tienes copias. Cómo detectarlo: pregúntate si, con tu método actual, puedes responder en diez segundos "¿qué cambió exactamente entre la versión del martes y la de hoy, y quién lo cambió y por qué?". Si la respuesta es "tendría que abrir los dos archivos y compararlos a ojo", no estás versionando, estás acumulando copias. Cómo corregirlo: eso es justamente lo que resuelve el módulo. El Módulo 1 ya mostró por qué exportar/importar tiene límites; aquí les ponemos encima la herramienta que los cubre.

Ejercicios

Ejercicio 1 — Diagnostica tu método actual. Piensa en cómo guardas hoy las versiones de tus workflows (o de cualquier archivo importante: un documento, una hoja de cálculo). Anota, con honestidad, cómo responderías estas cuatro preguntas con tu método de hoy: (a) ¿cuál era la versión que funcionaba hace exactamente una semana?, (b) ¿qué cambió entre esa versión y la actual?, (c) ¿quién hizo ese cambio y por qué?, (d) si necesitaras volver a la de hace una semana, ¿cuánto tardarías y qué tan seguro estarías de haber tomado la correcta?

Ver solución

No hay una respuesta única; el valor está en tu propia respuesta. El patrón que casi todos encontramos al hacer este ejercicio con sinceridad es que las cuatro preguntas se responden con alguna versión de "no estoy seguro" o "tendría que ponerme a buscar y comparar a mano". Eso no es un defecto tuyo: es la limitación real del método de copias fechadas, que se siente sólido hasta que lo interrogas.

Guarda tus cuatro respuestas. Al terminar el módulo, vuelve a ellas: con Git, las cuatro se contestan con un comando y con certeza. La (a) la responde git log; la (b), git diff; la (c), el autor y el mensaje de cada commit; la (d), un git revert o un git checkout de treinta segundos. Ver el "antes" escrito de tu puño hace que el "después" se sienta como lo que es: una mejora concreta, no una moda técnica.

Ejercicio 2 — Traduce la promesa del mercado. La frase que citamos, "as version-controlled, documented JSON", tiene tres partes. Explica con tus palabras qué exige cada una y en qué módulo o lección de esta guía se aprende: (a) "version-controlled", (b) "documented", (c) "JSON".

Ver solución

(a) "Version-controlled" (bajo control de versiones): que el workflow tenga un historial real —quién cambió qué, cuándo y por qué— y que puedas moverte por ese historial. Es, literalmente, todo este Módulo 2.

(b) "Documented" (documentado): que junto al workflow haya una explicación legible de qué hace, cómo se usa y qué necesita para correr —normalmente un archivo README—. Eso se ve más adelante, en el Módulo 3, cuando estructuramos el repositorio para el handoff. Los mensajes de commit que aprendes en la lección 3 son ya una primera forma de documentación: cada cambio queda explicado.

(c) "JSON": que la unidad que entregas sea el workflow exportado en su formato de texto, no una captura de pantalla ni una descripción. Exportar a JSON lo viste en el Módulo 1; normalizarlo para que sea limpio y diffeable es el Módulo 3.

Por qué funciona: el ejercicio conecta una frase de oferta de trabajo real con el plan de estudio concreto. Cuando en una entrevista te pregunten si sabes entregar "version-controlled, documented JSON", vas a poder responder no con un "sí" vago, sino describiendo exactamente qué hiciste para cada palabra.

Ejercicio 3 — Anticipa el hilo. Sin volver a mirar la tabla del hilo del módulo, escribe de memoria qué le pasa al workflow order-triage en cada una de las siete lecciones que siguen (2 a 8), en una frase cada una. Después compara con la tabla y marca las que se te escaparon.

Ver solución

(2) Instalas Git y conviertes la carpeta del proyecto en un repositorio. (3) Haces tu primer commit —la primera foto— y aprendes a hacerlos limpios. (4) Cambias el workflow y aprendes a leer el diff que muestra qué cambió. (5) Experimentas una idea nueva en una rama aparte, sin tocar la versión buena. (6) Subes el historial a GitHub para respaldarlo y compartirlo. (7) Reviertes un cambio que rompió el workflow y vuelves a la versión que servía. (8) Juntas todo en el proyecto entregable.

Por qué funciona: si reconstruiste al menos cinco de las siete, ya internalizaste que el módulo no son ocho temas de Git sueltos, sino la vida de un cambio en un workflow —guardar, comparar, experimentar, compartir, revertir—. Las que más se escapan suelen ser la 4 (diffs) y la 7 (rollback), que son las que todavía no tienen una imagen concreta en tu cabeza. Después de sus lecciones, no se te van a olvidar.

Resumen y siguiente paso

En esta lección viste por qué el método natural de versionar —copias con la fecha en el nombre— falla justo cuando más lo necesitas: no dice qué cambió, ni quién, ni por qué, no deja experimentar sin riesgo y convierte "volver atrás" en abrir archivos viejos y adivinar. Viste por qué Git es la herramienta correcta y no Dropbox, Google Drive ni el historial interno de n8n: Git fue diseñado para llevar el historial de archivos de texto —y un workflow exportado es texto— de forma que puedas comparar, agrupar cambios con intención, trabajar en paralelo y volver a cualquier punto con precisión. Separaste dos nombres que la gente mezcla todo el tiempo: Git es el programa local; GitHub es un sitio opcional para alojar una copia. Y recibiste el hilo del módulo: order-triage de Cumbre, que vas a poner bajo control de versiones paso a paso hasta un remoto compartido.

Antes de avanzar a la lección 2 deberías poder: explicar en una frase por qué las copias fechadas no son control de versiones; decir la diferencia entre Git y GitHub; y nombrar al menos cuatro de las siete lecciones que siguen, con lo que le pasa a order-triage en cada una.

Lo que no hiciste todavía es lo más importante: tocar Git de verdad. Hasta aquí solo miramos el mapa. La lección 2 baja al terreno: vas a instalar Git en tu máquina —con el camino específico para tu sistema operativo—, a configurarlo con tu nombre para que tus commits lleven autor, y a correr tu primer git init sobre la carpeta cumbre-automations, viendo con tus propios ojos cómo una carpeta común se convierte en un repositorio. Nada de teoría abstracta: un comando, una respuesta en la terminal, y una explicación de qué acaba de pasar.

Recursos

• What is Git? — Git Docs — el primer capítulo del libro oficial de Git, gratuito y en línea. Explica de dónde viene Git y por qué guarda el historial como lo guarda. Denso pero autorizado.
• About Version Control — Git Docs — la introducción conceptual al control de versiones, útil para reforzar por qué las copias a mano se quedan cortas.
• Source control (Git) — n8n Docs — la página oficial de n8n sobre control de versiones y entornos. Describe lo que trae la plataforma de forma nativa; nos sirve para tener presente la frontera Community/Enterprise que el Módulo 6 discute a fondo.
• Export and import workflows — n8n Docs — cómo se exporta un workflow a JSON, el archivo que vamos a versionar. Repaso del Módulo 1 por si necesitas refrescarlo antes de la lección 2.