8. Proyecto: un workflow bajo control de versiones

Descripción

Al terminar esta lección vas a tener construido y funcionando el entregable que resume todo el módulo: el workflow order-triage de Cumbre bajo control de versiones de punta a punta. Vas a haber puesto el workflow en Git, iterado sobre él en tres ramas distintas, revisado cada cambio con su diff, fusionado las tres a main, revertido un cambio concreto de forma limpia, y conectado todo a un remoto en GitHub. El resultado es un repositorio con historial legible y un cambio revertido con trazabilidad —exactamente lo que el mercado pide cuando dice "version-controlled JSON", y una prueba, defendible en una entrevista, de que cruzaste la frontera de constructor de workflows a dueño del sistema.

Esto importa porque es la diferencia entre haber leído sobre Git y saber usarlo sobre un workflow real. Las siete lecciones anteriores te dieron cada pieza por separado: instalar, commitear, diffear, ramificar, respaldar, revertir. Nada de eso se fija hasta que lo encadenas en un flujo completo, ves el historial crecer con tus decisiones, y al final puedes mirar tu git log y leer en él la historia entera de tu trabajo. Ese git log legible es tu artefacto de portafolio: el objeto concreto que pones sobre la mesa en una entrevista técnica.

Conexión con el módulo: esta lección no introduce ningún concepto nuevo. Ensambla los siete anteriores. El repositorio de la lección 2 es donde trabajas; los commits de la lección 3 son cada foto; los diffs de la lección 4 son cómo revisas; las ramas de la lección 5 son las tres iteraciones; el remoto de la lección 6 es dónde lo respaldas; y el revert de la lección 7 es el cierre limpio. Si algo de lo que sigue no te resulta familiar, ese es el número de lección al que conviene volver antes de continuar.

Lo que vas a entregar

Un repositorio cumbre-automations, alojado en GitHub, con un historial que cuenta esta historia de principio a fin. Al terminar, tu git log --oneline debe verse muy parecido a esto —el mismo bloque con el que abrimos la lección 1, ahora construido por ti—:

f1a2b3c (HEAD -> main) Revert "Point CRM lookup at the staging URL"
e9d8c7b Point CRM lookup at the staging URL
d4e5f6a Add priority routing after classification
b2c4d6e Widen CRM lookup timeout to 15 seconds
a91c3f8 Add wholesale category to the order classifier
c08b4a2 Add order-triage workflow

Ese historial no es decorativo: cada línea es una decisión tuya, tomada con criterio. Tres de los commits del medio llegaron por ramas de feature distintas que fusionaste. El de arriba es un rollback limpio de un cambio que rompió el workflow. Y todo está respaldado en un remoto.

Junto al repositorio, dos entregables que no son comandos y valen tanto como ellos:

1. Una defensa de portafolio de unas cinco frases: por qué cada decisión de tu historial fue la correcta (fase 8). Es lo que responderías en una entrevista mirando tu propio git log.
2. Tu repositorio en GitHub, privado, con la historia completa subida.

Sobre el tiempo: el proyecto entero toma alrededor de una hora si vas siguiendo. La fase 6 —el rollback— es la que no conviene saltarse, porque es donde todo el módulo se justifica.

Una nota sobre los folios. En todos los ejemplos vas a ver folios de commit como c08b4a2 o f1a2b3c. Los tuyos van a ser distintos —Git los calcula a partir del contenido, la fecha y tu autor, así que es imposible que coincidan con los míos—. Cuando un paso te pida usar un folio, tómalo de tu git log, no lo copies de la guía. Es el mismo principio de siempre: verifica contra tu propia máquina.

Por qué este orden de fases. No es arbitrario, y vale la pena verlo. Primero preparas el terreno (fase 0) e inicializas con un commit base (fase 1), porque no puedes ramificar sobre la nada. Después las tres ramas (fases 2 a 4) antes de fusionar, para tener varios experimentos vivos a la vez y practicar la independencia entre ellos. Luego revisas y fusionas (fase 5), que es donde los diffs se ganan su lugar. Solo entonces el rollback (fase 6), porque necesitas una historia con varios commits para que revertir uno concreto tenga sentido. Y al final GitHub (fase 7) y la defensa (fase 8), porque respaldar y explicar vienen después de construir. Es, en miniatura, el ciclo de vida completo de un cambio en un workflow: se guarda, se experimenta, se integra, se corrige, se comparte, se defiende.

Fase 0 — Preparar el terreno

Necesitas dos cosas: el workflow order-triage exportado como JSON, y una máquina con Git configurado (lección 2).

Paso 0.1. Confirma que Git está listo:

git --version
git config --list

Deberías ver una versión 2.x y tus user.name y user.email. Si algo falta, vuelve a la lección 2.

Paso 0.2. Crea la carpeta del proyecto y coloca dentro tu order-triage.json (el workflow de Cumbre que recibe pedidos con un Webhook, los clasifica con un AI Agent y consulta el CRM con un HTTP Request). Si vienes trabajando el workflow desde las lecciones anteriores, ya lo tienes; si empiezas limpio aquí, expórtalo desde n8n con la opción de descargar, que produce JSON multilínea —más amable para los diffs, como viste en la lección 4—.

mkdir cumbre-automations
# (coloca order-triage.json dentro de la carpeta)
cd cumbre-automations

Paso 0.3. Protege los secretos desde el primer momento. Crea un .gitignore (lección 3) para que ninguna credencial entre al historial por accidente:

# .gitignore
.DS_Store
.env
credentials.json
*.key

Un momento para notar algo. Todavía no has corrido git init. Estás poniendo el terreno en orden antes de empezar a versionar: el archivo a versionar y la lista de lo que nunca se versiona. Ese orden —preparar antes de inicializar— evita el error más común de los primeros commits, que es fotografiar un secreto sin darte cuenta.

Fase 1 — Inicializar y el commit base

Paso 1.1. Convierte la carpeta en repositorio:

git init

Qué esperar: Initialized empty Git repository in .../cumbre-automations/.git/. Confirma con git status que order-triage.json aparece como "Untracked files" y que tu .gitignore también está ahí (el .gitignore sí se versiona; es lo que se ignora lo que no entra).

Paso 1.2. Haz el commit base —la primera foto, el punto de partida honesto del workflow—:

git add order-triage.json .gitignore
git commit -m "Add order-triage workflow"

Qué esperar:

[main (root-commit) c08b4a2] Add order-triage workflow
 2 files changed, 129 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 order-triage.json

Ese (root-commit) marca que es la raíz de tu historial. A partir de aquí, todo crece hacia arriba. Verifica con git log --oneline que tienes tu primer commit con HEAD -> main al lado.

Fase 2 — Rama 1: agregar la categoría wholesale

Ahora las tres iteraciones, cada una en su rama. La primera: agregar la categoría wholesale al clasificador, porque Cumbre empezó a distinguir a sus clientes mayoristas.

Paso 2.1. Crea la rama y muévete a ella:

git switch -c add-wholesale-category

Qué esperar: Switched to a new branch 'add-wholesale-category'.

Paso 2.2. En n8n, abre order-triage, entra al nodo Classify Order (el AI Agent) y agrega wholesale a su lista de categorías (standard, priority → standard, priority, wholesale). Guarda, exporta y reemplaza tu order-triage.json.

Paso 2.3. Revisa el cambio antes de guardarlo, aplicando las cuatro reglas de leer a través del ruido (lección 4):

git diff

Salta el versionId y las posiciones; detente en el parameters del nodo Classify Order. Deberías ver la categoría agregada. Confirma que es el cambio que querías y solo ese.

Paso 2.4. Guarda:

git add order-triage.json
git commit -m "Add wholesale category to the order classifier"

El commit se guardó en la rama add-wholesale-category, no en main. Tu marcapáginas de feature avanzó; el de main sigue en el commit base.

Fase 3 — Rama 2: ampliar el timeout del CRM

Segunda iteración, segunda rama, partiendo siempre de main para que las ramas sean independientes.

Paso 3.1. Vuelve a main y crea la segunda rama desde ahí:

git switch main
git switch -c widen-crm-timeout

Fíjate en el detalle: volviste a main antes de crear la segunda rama. Así widen-crm-timeout sale del commit base, no de la rama anterior. Son tres experimentos paralelos e independientes, no una cadena.

Paso 3.2. En n8n, entra al nodo Lookup Customer in CRM (el HTTP Request) y sube su timeout de 5 a 15 segundos, porque el CRM a veces tarda bajo carga. Guarda, exporta, reemplaza el archivo.

Paso 3.3. Revisa con git diff (busca el timeout dentro de los options del nodo del CRM) y guarda:

git add order-triage.json
git commit -m "Widen CRM lookup timeout to 15 seconds"

Fase 4 — Rama 3: enrutar los pedidos priority

Tercera iteración: agregar un paso que enrute los pedidos priority después de clasificarlos.

Paso 4.1. De nuevo, parte desde main:

git switch main
git switch -c add-priority-routing

Paso 4.2. En n8n, agrega el nodo de enrutamiento (por ejemplo un Switch que dirija según la categoría del pedido), conéctalo después del clasificador, guarda, exporta y reemplaza el archivo.

Paso 4.3. Revisa con git diff —este cambio agrega un nodo entero, así que el diff será más grande; ubica el nodo nuevo y sus conexiones— y guarda:

git add order-triage.json
git commit -m "Add priority routing after classification"

Ahora tienes tres ramas de feature, cada una con un cambio, ninguna fusionada todavía. Míralo con el mapa de ramas de la lección 5:

git switch main
git log --oneline --all --graph

Qué esperar: el árbol bifurcado, con las tres ramas saliendo del commit base, cada una con su commit. Es la foto de tres experimentos vivos en paralelo, sobre una main que sigue intacta.

Fase 5 — Revisar y fusionar a main

Aquí decides qué entra. En un flujo real revisarías cada rama con cuidado —quizá en un Pull Request de GitHub (lección 6)— antes de fusionar. Vamos a revisar con diffs y fusionar las tres.

Paso 5.1. Desde main, revisa qué trae cada rama antes de fusionarla, comparando la rama contra main:

git diff main add-wholesale-category

Esto te muestra exactamente lo que la fusión agregaría. Repítelo para las otras dos ramas. Revisar antes de fusionar es el hábito profesional: nunca traes a main algo que no revisaste.

Paso 5.2. Fusiona la primera rama:

git merge add-wholesale-category

Qué esperar: un Fast-forward, porque main no se había movido. Ahora main tiene la categoría wholesale.

Paso 5.3. Fusiona la segunda:

git merge widen-crm-timeout

Qué esperar: aquí puede que ya no sea un Fast-forward. Como main avanzó al fusionar la primera rama, esta segunda rama y main divergieron un poco, y Git creará un merge commit que une las dos líneas —o, si los cambios tocaron partes distintas del archivo, las combinará solo—. Si por casualidad los dos cambios tocaron la misma zona del JSON, aparecerá un conflicto: resuélvelo como en la lección 5 (identifica los dos lados, quédate con lo correcto, borra los marcadores, o reemplaza con una exportación limpia de n8n).

Paso 5.4. Fusiona la tercera:

git merge add-priority-routing

Paso 5.5. Limpia las ramas ya fusionadas y mira el resultado:

git branch -d add-wholesale-category widen-crm-timeout add-priority-routing
git log --oneline

Tu main ahora contiene los tres cambios. El historial exacto puede variar según hubo o no merge commits, pero deberías reconocer tus tres features integradas sobre el commit base.

Qué mirar antes de seguir. Confirma tres cosas antes de pasar al rollback. Primero, que git status diga working tree clean —todo lo fusionado está guardado—. Segundo, que git branch muestre solo main —las tres ramas de feature ya cumplieron su función y las borraste—. Tercero, que tu order-triage.json, importado de vuelta en n8n, tenga las tres cosas a la vez: la categoría wholesale, el timeout de 15 segundos y el nodo de enrutamiento. Ese último chequeo es el que de verdad importa: comprueba que las tres ramas independientes se integraron en un solo workflow coherente, que es el punto de fusionar. Si una feature se perdió por el camino —por un conflicto mal resuelto, por ejemplo— es aquí donde lo detectas, no en producción.

Fase 6 — El rollback: revertir un cambio que rompió el workflow

Esta es la fase que justifica todo el módulo. Vamos a reproducir el "martes malo" de Cumbre: introducir un cambio que rompe el workflow y luego revertirlo con limpieza.

Paso 6.1. Sobre main, haz el cambio malo: en n8n, apunta la url del nodo Lookup Customer in CRM al servidor de staging (https://crm.cumbre.example/... → https://crm-staging.cumbre.example/...). Guarda, exporta, reemplaza el archivo. Guárdalo:

git add order-triage.json
git commit -m "Point CRM lookup at the staging URL"

Paso 6.2. Imagina que ahora los pedidos mayoristas dejan de enrutarse: staging no tiene esos clientes. Diagnostica antes de actuar, con el diff que confirma la causa:

git diff HEAD~1 HEAD

Deberías ver, entre el ruido, que lo único que cambió es la url del CRM, de producción a staging. Causa confirmada.

Paso 6.3. Revierte el commit malo, la vía segura (lección 7):

git revert HEAD --no-edit

(El --no-edit acepta el mensaje automático Revert "Point CRM lookup at the staging URL" sin abrir el editor.)

Qué esperar:

[main f1a2b3c] Revert "Point CRM lookup at the staging URL"
 1 file changed, 1 insertion(+), 1 deletion(-)

Paso 6.4. Lee el historial final:

git log --oneline

Deberías ver, arriba de todo, el commit de revert, y justo debajo el commit malo que sigue en la historia —no lo borraste, lo corregiste—. Tu order-triage.json apunta el CRM a producción de nuevo. El incidente quedó cerrado con trazabilidad: cualquiera que lea el historial ve que se cometió un error y se corrigió, con fecha y autor.

Fase 7 — Conectar y subir a GitHub

Paso 7.1. En GitHub, crea un repositorio vacío y privado llamado cumbre-automations (sin README ni ninguna casilla marcada, lección 6). Copia su URL.

Paso 7.2. Conecta y sube:

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

Resuelve la autenticación cuando aparezca (asistente del navegador, o PAT/SSH según tu sistema).

Paso 7.3. Abre la URL en el navegador y verifica: debes ver tu order-triage.json, tu .gitignore, y la lista completa de commits con sus notas y tu nombre. Ahí está tu entregable, respaldado y compartible.

Fase 8 — La defensa de portafolio

Última entrega, y no es un comando. Escribe cinco frases que respondan la pregunta que te haría un entrevistador mirando tu git log: "Explícame las decisiones detrás de este historial."

Es exactamente la conversación para la que este módulo te preparó. La respuesta "fui haciendo cambios" no sirve; la buena nombra los conceptos por su nombre. Una versión de referencia, para que veas el nivel esperado:

"Cada feature vive en su propio commit con un mensaje en imperativo que dice qué cambió y en qué nodo, así que el historial se lee sin abrir el JSON. Trabajé cada cambio en una rama de feature separada, saliendo siempre de main, para que main estuviera siempre lista para producción y ningún experimento la pusiera en riesgo. Revisé cada rama con un diff antes de fusionarla, leyendo a través del ruido del JSON de n8n para separar la lógica real de los metadatos de la plataforma. Cuando un cambio apuntó el CRM a staging y rompió el enrutamiento, lo diagnostiqué con git diff y lo deshice con git revert —no con reset— porque el commit ya estaba en la historia compartida, y así el rollback quedó registrado y auditable en lugar de borrado. Y todo está en un repositorio privado de GitHub, que le da al equipo respaldo y un punto común de trabajo que la edición Community de n8n no trae de forma nativa."

Fíjate en lo que hace esa respuesta: no describe comandos, describe criterio. Nombra por qué cada decisión fue la correcta y qué se habría roto con la alternativa. Eso es lo que separa a quien "sabe Git" de quien entiende para qué sirve. Y es, palabra por palabra, la clase de conversación que la lección 1 prometió que te habilitaría.

Un consejo sobre cómo presentar esto en una entrevista, porque el artefacto por sí solo no habla. Comparte la pantalla, abre tu git log --oneline y recórrelo de abajo hacia arriba como quien cuenta una historia: "aquí está el workflow base; estas tres las trabajé en ramas separadas para no arriesgar producción; aquí alguien apuntó el CRM a staging y lo rompió; y aquí lo revertí de forma auditable en vez de borrarlo". En treinta segundos demostraste, sobre un objeto real, que entiendes el ciclo de vida completo de un cambio. Casi nadie que aplica a un puesto de automatización llega con esto; la mayoría llega con capturas de workflows bonitos. Un git log que se lee como una historia es una señal de madurez profesional que difícilmente pasa desapercibida.

Criterios de entrega

Repásalos antes de dar por cerrado el proyecto:

• El repositorio cumbre-automations existe, tiene git init hecho y un .gitignore que excluye credenciales.
• El commit base Add order-triage workflow es la raíz del historial.
• Hiciste tres cambios en tres ramas distintas, cada una salida de main, y las fusionaste.
• Cada commit tiene un mensaje en inglés, en imperativo, específico sobre qué nodo o parámetro tocó.
• Revisaste al menos una rama con git diff antes de fusionarla, y puedes decir qué cambió de verdad y qué era ruido.
• Hay un cambio revertido con git revert, y el commit malo sigue en la historia debajo de su revert.
• git log --oneline se lee de corrido y cuenta la historia del workflow sin ambigüedad.
• El repositorio está subido a GitHub, privado, con toda la historia visible en la web.
• Tienes escrita la defensa de portafolio de cinco frases.

Extensiones opcionales

Si quieres seguir practicando antes de entrar al Módulo 3, tres ideas de dificultad creciente. Ninguna requiere nada que no hayas visto:

Fácil. Recupera la versión de order-triage.json del commit base con git checkout <folio-base> -- order-triage.json, obsérvala, y luego descártala con git restore order-triage.json para volver a la actual. Practicas recuperar y descartar sin ensuciar el historial.

Media. Simula un compañero: en otra carpeta, git clone de tu repositorio de GitHub, haz un cambio en el clon, súbelo con git push, y desde tu carpeta original tráelo con git pull. Comprueba que el cambio viajó de una copia a la otra pasando por el remoto.

Difícil. Crea una rama try-urgent-category que agregue una categoría urgent al clasificador, haz un commit en ella, y luego decide no fusionarla: bórrala con git branch -D desde main y comprueba con git log --oneline que main quedó exactamente como si el experimento nunca hubiera pasado. Practicas tirar un experimento sin dejar cicatriz.

Errores comunes

Encadenar las ramas en vez de sacarlas todas de main (práctico). Qué pasa: se crea la segunda rama sin volver antes a main, quedando widen-crm-timeout colgada de add-wholesale-category en lugar de del commit base; al fusionar, la segunda rama arrastra los cambios de la primera y el historial se enreda. Por qué pasa: es fácil olvidar volver a main entre rama y rama. Cómo detectarlo: el mapa git log --oneline --all --graph te lo muestra —si las ramas salen una de otra en cadena en vez de en abanico desde el commit base, están encadenadas—. Cómo corregirlo: adopta el ritmo git switch main antes de cada git switch -c nueva-rama. Para experimentos independientes, cada rama sale del mismo punto.

Fusionar sin revisar el diff (conceptual). Qué pasa: se fusiona cada rama a ciegas con git merge sin mirar antes qué trae, y algo indeseado —un nodo movido de más, un cambio a medias— entra a main sin que nadie lo viera. Por qué pasa: fusionar es un comando de una línea y revisar se siente opcional. Cómo detectarlo: si no puedes decir qué cambió cada merge, no revisaste. Cómo corregirlo: haz git diff main <rama> antes de cada git merge, y lee el resultado con las cuatro reglas de la lección 4. En equipo, esta revisión es el Pull Request; en solitario, es disciplina tuya. main solo recibe lo revisado.

Usar reset en vez de revert para el rollback de la fase 6 (conceptual). Qué pasa: para deshacer el cambio malo se usa git reset --hard HEAD~1 en lugar de git revert, borrando el commit malo de la historia. Por qué pasa: reset se siente más "limpio" porque el commit malo desaparece. Cómo detectarlo: si tras el rollback el commit Point CRM lookup at the staging URL ya no aparece en git log, usaste reset. Cómo corregirlo: para este proyecto —y para casi todo lo que va a un remoto compartido— la vía correcta es revert, que conserva el commit malo y le agrega su corrección. El entregable pide, precisamente, un rollback auditable: el valor está en que el error siga visible junto a su enmienda. reset borraría esa auditoría.

Subir el repositorio como público, o con un secreto dentro (práctico y serio). Qué pasa: se crea el repo de GitHub como público, o se sube sin haber puesto el .gitignore, exponiendo lógica de negocio o una credencial. Por qué pasa: la opción de público a veces está preseleccionada, y sin .gitignore un secreto cercano se cuela fácil. Cómo detectarlo: antes del push, revisa con git log y git status qué está versionado; en GitHub, confirma que el repo diga "Private". Cómo corregirlo: repo privado por defecto, y .gitignore desde el commit base (fase 0). Si ya subiste un secreto, cambiar a privado no basta: hay que rotar el secreto y limpiarlo del historial, un tema del Módulo 3. Piensa en visibilidad y secretos antes de empujar.

Ejercicios

Ejercicio 1 — Audita tu propio historial. Abre tu git log --oneline terminado y, poniéndote en el lugar de un revisor externo que no vio cómo lo construiste, responde: ¿puedes entender qué hace cada commit solo con su mensaje, sin abrir el JSON? ¿Hay algún mensaje vago que reescribirías? ¿El rollback se entiende como tal? Anota qué mejorarías.

Ver solución

No hay una respuesta única; el valor está en mirar tu propio trabajo con ojos ajenos. La prueba concreta es esta: tápate el código y lee solo la columna de mensajes. Si la historia se entiende de corrido —"se agregó el workflow, luego la categoría wholesale, luego se amplió el timeout, luego el enrutamiento de priority, luego alguien apuntó el CRM a staging y se revirtió"— tu historial pasa la prueba. Si algún mensaje te obliga a abrir el commit para saber qué hizo, ese es el que reescribirías.

Por qué funciona: auditar tu propio historial es la habilidad que de verdad importa, porque el historial lo van a leer otros (o tu yo del futuro) sin el contexto que tú tienes hoy fresco. Un git log que se entiende sin abrir un solo commit es la marca de un repositorio profesional, y es lo primero que mira quien evalúa tu portafolio.

Ejercicio 2 — Explica el rollback a alguien que no sabe Git. Imagina que un colega de Cumbre que nunca usó Git te pregunta: "¿por qué el commit malo sigue ahí? ¿no sería más limpio borrarlo?". Respóndele en tres o cuatro frases, sin jerga, explicando por qué conservar el commit malo junto a su revert es mejor que borrarlo.

Ver solución

Una buena respuesta va por aquí: borrar el commit malo escondería que el error ocurrió, y en un equipo eso es peor que dejarlo visible —nadie aprendería de él, y si alguien más tenía una copia con ese commit, las dos historias dejarían de coincidir y se armaría un lío—. Conservarlo junto a su corrección es como una línea de ajuste en un libro de cuentas: el error queda a la vista y también su enmienda, así que cualquiera puede auditar qué pasó, quién lo hizo y cómo se resolvió. La historia dice la verdad completa, que es justo lo que quieres cuando algo salió mal.

Por qué funciona: poder explicar un concepto técnico sin jerga, a alguien que no lo conoce, es la prueba más honesta de que lo entendiste tú. Y esta explicación en particular —trazabilidad sobre borrado— es el corazón de por qué el control de versiones profesional prefiere revert a reset en lo compartido. Si puedes defenderlo ante un colega, puedes defenderlo en una entrevista.

Ejercicio 3 — Diseña la siguiente iteración. Cumbre te pide un cambio nuevo: agregar un nodo que registre cada pedido clasificado en una hoja de cálculo, para auditoría. Sin escribir el código, describe el flujo de Git completo que seguirías para hacer este cambio de forma profesional, desde antes de tocar n8n hasta que el cambio esté en main en GitHub. Nombra cada comando.

Ver solución

Un flujo profesional completo:

1. git switch main y git pull — parte de una main limpia y actualizada con lo que haya en el remoto.
2. git switch -c add-order-logging — crea la rama de feature para este cambio.
3. Haces el cambio en n8n (agregas el nodo de registro), guardas y exportas, reemplazando order-triage.json.
4. git diff — revisas que el cambio sea el que querías y solo ese, leyendo a través del ruido.
5. git add order-triage.json y git commit -m "Log classified orders to the audit sheet" — guardas con un mensaje claro.
6. git switch main y git diff main add-order-logging — vuelves a main y revisas qué traería la fusión.
7. git merge add-order-logging — fusionas (resolviendo conflicto si aparece).
8. git branch -d add-order-logging — limpias la rama fusionada.
9. git push — subes main actualizada al remoto.

Por qué funciona: este ejercicio te pide orquestar el módulo entero como un solo movimiento fluido, que es exactamente lo que harás en el trabajo real cada vez que toques un workflow. Cuando este flujo te salga de memoria —sin pensar en cada comando por separado— dejaste de "saber comandos de Git" y empezaste a tener un proceso, que es lo que hace un dueño de sistema de automatización.

Resumen y siguiente paso

Con este proyecto cierras el Módulo 2. Tomaste order-triage de Cumbre y lo pusiste bajo control de versiones de punta a punta: lo inicializaste con un .gitignore que protege los secretos, hiciste el commit base, iteraste sobre él en tres ramas distintas —categoría wholesale, timeout del CRM, enrutamiento de priority—, revisaste cada una con su diff antes de fusionarla a main, reprodujiste el "martes malo" de Cumbre y lo cerraste con un git revert limpio y auditable, y subiste todo a un repositorio privado de GitHub. Y escribiste la defensa de portafolio: la conversación, apoyada en criterio y no en comandos, que te van a pedir en una entrevista mirando tu git log.

Ahora puedes: instalar y configurar Git; crear un repositorio; hacer commits limpios con buenos mensajes; leer diffs a través del ruido del JSON de n8n; experimentar en ramas sin arriesgar la versión buena; respaldar y compartir en GitHub; y volver atrás cuando algo se rompe, con precisión, trazabilidad y confianza. No está mal para no haber sabido, hace ocho lecciones, qué era un commit.

Y ese es justamente el punto de partida del Módulo 3. En este módulo convivimos con una molestia que aplazamos a propósito una y otra vez: el ruido del JSON de n8n —los versionId, las posiciones del lienzo, el pinData— que ensucia cada diff y agranda cada conflicto. Aprendiste a leer a través de ese ruido, que era la habilidad correcta para trabajar hoy. El Módulo 3 lo elimina de raíz: vas a exportar los workflows con la CLI de n8n, a separar las credenciales del repositorio de una vez por todas, a normalizar el JSON para que tus diffs salgan tan limpios como el "mundo ideal" que viste en la lección 4, y a estructurar y documentar el repositorio para el handoff —la parte "documented" de "version-controlled, documented JSON"—. Tienes el ciclo de vida bajo control; ahora vamos a dejar el repositorio impecable.

Recursos

• Git Basics — Git Docs — el capítulo que recorre el ciclo completo que ensamblaste en este proyecto, de init a push. Buen repaso integral.
• git merge — Git Docs — la referencia de la fusión, útil para las tres fusiones de la fase 5 y para entender cuándo aparece un merge commit en vez de un fast-forward.
• git revert — Git Docs — la referencia del rollback auditable de la fase 6, con la opción --no-edit.
• Source control and environments — n8n Docs — el trasfondo de cómo n8n concibe el control de versiones, que el Módulo 3 y el Módulo 6 desarrollan; útil para ubicar lo que hiciste a mano frente a lo que la plataforma ofrece.
• Export and import workflows — n8n Docs — cómo exportar el workflow que versionaste; el Módulo 3 lo lleva a la exportación con la CLI para diffs limpios.