Módulo 2: Git desde cero para automatizadores

4. Leer el diff de un workflow

Siguiente →

Descripción

Al terminar esta lección vas a poder responder la pregunta que el control de versiones existe para responder: ¿qué cambió, exactamente, entre dos versiones de mi workflow? Vas a saber qué es un diff y cómo leer su anatomía —los encabezados, los marcadores de bloque, las líneas que se quitaron y las que se agregaron—, vas a manejar git diff en sus tres formas más útiles, y vas a leer un cambio real dentro de order-triage identificando qué nodo se tocó y qué parámetro. Y vas a enfrentar de cara una realidad incómoda: el JSON de un workflow de n8n, tal como sale de la plataforma, produce diffs ruidosos, y vas a aprender a encontrar el cambio de verdad en medio de ese ruido.

Esto importa porque leer un diff es la habilidad que convierte a Git de "una caja donde guardo versiones" en "una herramienta que me deja entender cómo evolucionó mi sistema". Un historial que no puedes leer es casi tan inútil como no tener historial. Y en el trabajo real, leer diffs es lo que haces antes de aprobar un cambio, antes de fusionar una rama, antes de promover algo a producción y —el día del incidente— para encontrar qué lo rompió. Es, quizás, la destreza más transferible de todo el módulo.

Conexión con el módulo: esta es la bisagra. Las lecciones 2 y 3 fueron mecánica —instalar, inicializar, guardar—; útiles, pero todavía podrías pensar que Git es un botón de guardar con esteroides. Aquí es donde Git muestra para qué sirve de verdad. Vas a comparar los dos commits que ya tienes y a hacer un tercer cambio para compararlo también. Lo que aprendas aquí lo vas a usar en cada lección que sigue: para revisar una rama antes de fusionarla (lección 5), para entender qué trae un cambio de un compañero (lección 6) y para identificar qué commit revertir (lección 7). Y el ruido del JSON que vas a descubrir hoy es exactamente el problema que el Módulo 3 resuelve con la normalización; aquí lo nombramos y aprendemos a convivir con él, pero no lo resolvemos: esa es la frontera de este módulo.

Qué es un diff

Empecemos por la palabra. Diff es la abreviatura de difference, diferencia. Un diff es una comparación entre dos versiones de un archivo de texto que te muestra, línea por línea, qué se quitó y qué se agregó para pasar de una a la otra. No te muestra el archivo entero: te muestra solo lo que cambió, más unas pocas líneas de contexto alrededor para que ubiques dónde está el cambio.

Piénsalo como el modo "control de cambios" de un procesador de texto, ese donde lo que borraste aparece tachado y lo que agregaste aparece subrayado en otro color. Cuando le pasas un documento a alguien para que revise tus ediciones, no le mandas el documento nuevo a secas —tendría que leerlo entero y adivinar qué tocaste—; le mandas el documento con los cambios marcados, para que vea de un vistazo qué es distinto. Un diff de Git es exactamente eso, pero para cualquier archivo de texto, y generado automáticamente comparando dos versiones que Git ya tiene guardadas.

La diferencia clave con el "control de cambios" del procesador de texto es que Git trabaja por líneas. Su unidad es la línea completa: si cambiaste una sola palabra en una línea, Git te muestra esa línea entera como "quitada" y la línea entera nueva como "agregada". No te subraya la palabra suelta. Esto es importante para entender por qué el JSON de n8n se comporta como se comporta, y volvemos a ello más adelante.

La anatomía de un diff, leída con calma

Antes de generar uno sobre order-triage, veamos la forma general de un diff de Git con un ejemplo diminuto, para que cuando aparezca el de verdad no te tome por sorpresa. Supón un archivo de texto cualquiera donde cambiaste una línea:

diff --git a/order-triage.json b/order-triage.json
index c08b4a2..3e5d720 100644
--- a/order-triage.json
+++ b/order-triage.json
@@ -12,7 +12,7 @@
         "promptType": "define",
         "text": "=Classify this order.",
-        "timeout": 5000,
+        "timeout": 15000,
         "options": {}

Cada parte tiene un trabajo. Vamos de arriba hacia abajo:

  • diff --git a/order-triage.json b/order-triage.json: el título. Dice qué archivo se está comparando. La a/ es la versión vieja y la b/ es la nueva; son etiquetas convencionales de Git, no carpetas de verdad.
  • index c08b4a2..3e5d720 100644: información interna de Git —los folios de las dos versiones del archivo y sus permisos—. Puedes ignorarla el 99% del tiempo; está ahí para las tripas de Git.
  • --- a/order-triage.json y +++ b/order-triage.json: definen los dos lados de la comparación. Las tres rayas --- marcan la versión vieja; los tres signos +++ marcan la versión nueva. Grábate esta pareja: menos es lo viejo, más es lo nuevo. Es la clave para leer todo lo que sigue.
  • @@ -12,7 +12,7 @@: el encabezado de bloque —en inglés se llama hunk, "trozo"—. Te dice en qué parte del archivo está este cambio. Se lee así: el -12,7 significa "en la versión vieja, este trozo empieza en la línea 12 y abarca 7 líneas"; el +12,7, lo mismo para la versión nueva. Cuando un archivo tiene varios cambios en lugares distintos, vas a ver varios de estos encabezados @@, uno por cada zona tocada. Son tus marcadores de "el cambio está por aquí".
  • Las líneas de abajo son el cambio en sí. Fíjate en el primer carácter de cada una:
    • Las que empiezan con un espacio ( ) son contexto: líneas que no cambiaron, mostradas para que ubiques dónde estás. Aquí, "promptType": "define",, "text": ... y "options": {} no se tocaron.
    • La que empieza con - es una línea que se quitó (estaba en lo viejo, ya no está): "timeout": 5000,.
    • La que empieza con + es una línea que se agregó (no estaba en lo viejo, ahora está): "timeout": 15000,.

Leído todo junto, este diff cuenta una historia de una sola frase: en este workflow, el timeout pasó de 5000 a 15000. Una línea vieja quitada, una línea nueva puesta. Cuando cambias una palabra o un número dentro de una línea, así se ve siempre en Git: la línea entera sale como quitada y su versión nueva entra como agregada. No es que hayas borrado y reescrito todo; es la forma en que Git, que trabaja por líneas, representa un cambio dentro de una línea.

Con esta anatomía en la cabeza, cualquier diff se vuelve legible. Es siempre lo mismo: un título, dos lados (menos viejo, más nuevo), marcadores de zona (@@), y líneas de contexto, quitadas y agregadas. Vamos a generarlo de verdad.

Las tres formas de git diff que vas a usar

git diff compara dos cosas, pero cuáles dos cosas depende de cómo lo llames. Hay tres variantes que cubren casi todo lo que necesitas. La razón de que existan es directa: recuerda de la lección 3 que un cambio viaja por tres zonas —árbol de trabajo, área de preparación e historial—, y a veces quieres comparar unas contra otras.

1. git diff (a secas): lo que cambiaste pero aún no preparaste. Compara tu árbol de trabajo contra el área de preparación. Es decir, te muestra los cambios que hiciste y que todavía no metiste al encuadre con git add. Es la pregunta "¿qué he tocado desde la última vez que preparé?".

2. git diff --staged: lo que ya preparaste pero aún no guardaste. Compara el área de preparación contra el último commit. Te muestra exactamente lo que entraría en tu próximo commit si lo hicieras ahora. Es la revisión que haces justo antes de hacer commit: "¿esto que estoy a punto de guardar es lo que creo?". (También se escribe git diff --cached; son lo mismo.)

3. git diff <commit-viejo> <commit-nuevo>: qué cambió entre dos fotos del historial. Compara dos commits cualesquiera, usando sus folios. Es la pregunta que respondimos en la lección 1 —"¿qué cambió entre la versión del martes y la de hoy?"— y la más poderosa de las tres, porque te deja viajar por todo tu historial comparando cualquier par de puntos.

Hay una cuarta que conviene tener a mano: git diff HEAD compara tu árbol de trabajo contra el último commit, sin importar qué esté preparado y qué no. Es el "¿qué ha cambiado en total desde mi última foto?".

No hace falta memorizarlas hoy. Con el tiempo la mano las elige sola. Por ahora quédate con las dos más usadas: git diff para ver lo que acabas de tocar, y git diff <commit> <commit> para comparar dos versiones del historial.

Ejemplo trabajado: leer un cambio real en order-triage

Vamos a hacer un cambio de verdad en el workflow y a leerlo con git diff. El cambio: agregarle una categoría al clasificador. Hasta ahora, el nodo AI Agent de order-triage clasifica los pedidos en standard o priority; le vamos a añadir wholesale, porque Cumbre empezó a distinguir a sus clientes mayoristas.

Paso 1 — Parte de un árbol limpio. Confirma que no tienes cambios sueltos:

git status

Debe decir nothing to commit, working tree clean. Bien: cualquier diff que veamos ahora será del cambio nuevo, sin ruido de cambios viejos.

Paso 2 — Haz el cambio en n8n. Abre order-triage, entra al nodo Classify Order (el AI Agent), y en el texto de su instrucción cambia la lista de categorías de standard, priority a standard, priority, wholesale. Guarda, exporta el workflow y reemplaza tu order-triage.json.

Paso 3 — Pregunta qué cambió, sin preparar todavía.

git diff

Qué esperar (en el mundo ideal). Si el JSON estuviera limpio, verías algo tan legible como esto:

diff --git a/order-triage.json b/order-triage.json
index 3e5d720..a91c3f8 100644
--- a/order-triage.json
+++ b/order-triage.json
@@ -22,7 +22,7 @@
       "parameters": {
         "promptType": "define",
-        "text": "=Classify this order into one of: standard, priority.",
+        "text": "=Classify this order into one of: standard, priority, wholesale.",
         "options": {}
       },
       "name": "Classify Order",

Léelo con la anatomía que ya conoces. El encabezado @@ -22,7 +22,7 @@ te lleva a la zona del cambio. La línea de contexto de abajo, "name": "Classify Order", te dice qué nodo se tocó: el clasificador. Y el par menos/más te dice qué parámetro cambió y cómo: el text de la instrucción pasó de listar dos categorías a listar tres. Sin abrir n8n, sin recordar qué hiciste, el diff te lo cuenta entero: en el nodo Classify Order, se agregó la categoría wholesale a la instrucción del clasificador. Esa frase es la que escribirías como nota si fueras a hacer el commit —de hecho, es casi textual el Add wholesale category to the order classifier de la lección 1—.

Salir del diff. Igual que con git log, si el diff es largo y ocupa la pantalla, sales con la tecla q.

Ese "mundo ideal" es hacia donde vamos. Pero seamos honestos sobre lo que de verdad vas a ver hoy.

La realidad incómoda: el JSON de n8n produce diffs ruidosos

Aquí llega la parte que ningún temario del mercado te cuenta y que es medio módulo de por qué esta guía existe. El diff limpio de arriba es lo que querríamos ver. Lo que un workflow de n8n produce de fábrica es, casi siempre, más sucio. Hay dos versiones del problema, y conviene conocer las dos.

Problema A: el JSON en una sola línea gigante

Cuando exportas un workflow de ciertas formas —copiando y pegando los nodos, o con algunas configuraciones de exportación— el JSON sale minificado: todo el workflow en una sola línea larguísima, sin saltos ni sangría. Se ve como un muro de texto de miles de caracteres corridos.

Recuerda que Git trabaja por líneas. Si todo tu workflow es una línea, entonces cualquier cambio —por diminuto que sea— hace que Git vea "la línea 1 cambió", y como no puede mostrarte dentro de la línea, te muestra la línea entera como quitada y la línea entera como agregada. El diff se ve así:

@@ -1 +1 @@
-{"name":"order-triage","nodes":[{"parameters":{"httpMethod":"POST", ... (miles de caracteres) ... }]}
+{"name":"order-triage","nodes":[{"parameters":{"httpMethod":"POST", ... (miles de caracteres) ... }]}

Dos muros de texto casi idénticos, y en algún lugar de la diferencia entre ellos está tu cambio de una palabra. Es, para efectos prácticos, ilegible. Este es el peor caso, y es completamente real.

Problema B: el JSON multilínea, pero con ruido

La buena noticia es que la opción de descargar el workflow desde el editor de n8n normalmente produce un JSON con formato —multilínea y con sangría—, que ya se puede diffear mucho mejor que el muro de una línea. La mala noticia es que aun así viene con ruido: cambios que aparecen en el diff pero que no reflejan ninguna modificación real de la lógica de tu workflow. Los tres culpables más comunes:

  • El identificador de versión. Cada vez que guardas, n8n suele actualizar un campo interno como versionId. Ese valor cambia aunque no hayas tocado ningún nodo, así que aparece en todos tus diffs como una línea quitada y otra agregada, sin significar nada para ti.
  • Las posiciones en el lienzo. Cada nodo guarda su position, las coordenadas donde está en el canvas. Si arrastraste un nodo tres píxeles para acomodarlo visualmente, esa posición cambia y aparece en el diff —aunque mover un nodo no cambia en absoluto lo que el workflow hace—.
  • Los datos fijados (pinData). Si probaste el workflow con datos fijados —una técnica que verás en el Módulo 5—, esos datos de ejemplo se guardan en el JSON y ensucian el diff con contenido que no es lógica del workflow.

Un diff real, entonces, no se ve tan limpio como mi ejemplo ideal. Se ve más bien así, con tu cambio de verdad enterrado entre el ruido:

@@ -3,7 +3,7 @@
   "name": "order-triage",
-  "versionId": "a1b2c3d4-1111-2222-3333-444455556666",
+  "versionId": "f9e8d7c6-9999-8888-7777-666655554444",
   "nodes": [
@@ -18,7 +18,7 @@
         "promptType": "define",
-        "text": "=Classify this order into one of: standard, priority.",
+        "text": "=Classify this order into one of: standard, priority, wholesale.",
         "options": {}
@@ -40,7 +40,7 @@
       "name": "Classify Order",
       "typeVersion": 1.7,
-      "position": [200, 320],
+      "position": [208, 336],
       "id": "7c3e1a9b-..."

Hay tres zonas de cambio (@@), pero solo una es real: la del medio, donde se agregó wholesale. La primera es el versionId cambiando solo. La tercera es que, sin querer, moviste el nodo Classify Order unos píxeles al editarlo. Dos de los tres cambios son ruido.

La habilidad que sí puedes desarrollar hoy: leer a través del ruido

No vamos a resolver el ruido en esta lección —eso es el Módulo 3, con la normalización—. Pero sí puedes aprender a leer a través de él, que es una destreza valiosa por sí misma. La técnica es simple y consiste en saber qué ignorar:

  1. Salta las zonas de versionId, id, meta e instanceId. Son metadatos de la plataforma, no lógica tuya. Cuando un @@ solo toca uno de esos campos, pasa de largo.
  2. Salta las zonas de position. Un cambio de [200, 320] a [208, 336] es un nodo que se movió en el lienzo. Nunca es lógica; es cosmética del canvas.
  3. Salta las zonas de pinData si aparecen. Son datos de prueba, no configuración.
  4. Detente en los parameters. Ahí vive la lógica de verdad: la URL de un HTTP Request, el texto de instrucción de un AI Agent, la condición de un If, el path de un Webhook. El cambio que te importa casi siempre está dentro de un bloque "parameters": { ... }, y la línea de contexto "name": "..." cercana te dice de qué nodo es.

Con esas cuatro reglas, el diff ruidoso de arriba se lee en cinco segundos: ignoras el versionId (regla 1), ignoras la position (regla 2), y te quedas con la zona de en medio, que toca un parameters y está cerca de "name": "Classify Order". Ahí está tu cambio real. El ruido sigue estando; simplemente aprendiste a mirar a través de él.

Y aquí anuncio la frontera, sin cruzarla: en el Módulo 3 vas a aprender a eliminar ese ruido de raíz, normalizando el JSON antes de guardarlo —exportándolo siempre con formato consistente, quitando los campos volátiles como versionId y las posiciones, y ordenando las claves— para que tus diffs salgan tan limpios como mi "mundo ideal". Es un trabajo de configuración del repositorio que merece su propio espacio. Por ahora, saber leer a través del ruido es exactamente la habilidad correcta: te deja trabajar hoy, con lo que n8n produce de fábrica, mientras llega la solución de fondo.

Comparar dos commits del historial

La forma más útil de git diff a mediano plazo es comparar dos fotos del pasado. Ahora que tienes varios commits, puedes hacerlo.

Primero, mira tu historial para elegir qué comparar:

git log --oneline
a91c3f8 (HEAD -> main) Add wholesale category to the order classifier
3e5d720 Widen CRM lookup timeout to 15 seconds
c08b4a2 Add order-triage workflow

(Esto asume que ya guardaste el cambio de wholesale con un commit; si no lo has hecho, prepáralo y guárdalo con git add order-triage.json y git commit -m "Add wholesale category to the order classifier".)

Supón que quieres ver todo lo que cambió entre la primera versión del workflow y la actual. Tomas el folio del primer commit y el del último:

# git diff <viejo> <nuevo>: qué hay que cambiar para pasar del viejo al nuevo.
git diff c08b4a2 a91c3f8

Qué esperar. Un diff que junta todos los cambios entre esas dos fotos: el timeout que pasó de 5000 a 15000 (del segundo commit) y la categoría wholesale que se agregó (del tercero), más el ruido de metadatos que se acumuló por el camino. El orden importa: git diff viejo nuevo te muestra cómo llegar del viejo al nuevo; si los inviertes (git diff nuevo viejo), verías el cambio al revés —lo agregado aparecería como quitado—. La regla mnemotécnica: el primer folio es el punto de partida, el segundo es el destino.

Un atajo cómodo: si quieres comparar un commit contra tu versión actual, puedes usar HEAD en lugar de escribir el folio del último. git diff c08b4a2 HEAD compara el primer commit contra donde estás parado ahora. Y para comparar un commit contra el commit inmediatamente anterior, existe la notación a91c3f8~1 (el ~1 significa "uno antes de este"), pero eso es refinamiento; con los folios directos te alcanza para todo el módulo.

Errores comunes

Asustarse con el tamaño del diff y creer que rompiste algo (conceptual). Qué pasa: haces un cambio minúsculo —subir un timeout, cambiar una palabra— y git diff te devuelve una pantalla llena de líneas rojas y verdes. La conclusión instintiva es "cambié mucho más de lo que creía" o "algo se descompuso". Por qué pasa: es el ruido del JSON de n8n —versionId, posiciones, quizás un reordenamiento de claves al re-exportar— sumado a que Git muestra la línea entera aunque cambies una palabra. El tamaño del diff no es proporcional al tamaño del cambio real. Cómo detectarlo: aplica las cuatro reglas de "leer a través del ruido"; si al saltar metadatos y posiciones te queda un solo cambio de verdad en un parameters, el diff grande era casi todo ruido. Cómo corregirlo: no midas un cambio por el tamaño de su diff. Busca las zonas de parameters y evalúa esas. Y ten paciencia: el Módulo 3 hace que estos diffs adelgacen a su tamaño honesto.

Confundir git diff con git diff --staged y creer que "no hay cambios" (práctico). Qué pasa: modificas el archivo, corres git add, luego corres git diff para revisar y no ves nada; concluyes que tu cambio se perdió. Por qué pasa: git diff a secas compara el árbol de trabajo contra el área de preparación, y como ya preparaste todo con add, no queda diferencia entre esas dos zonas —tu cambio está en la de preparación, no "más adelante"—. Cómo detectarlo: si git diff sale vacío pero git status dice que hay algo en "Changes to be committed", el cambio está preparado. Cómo corregirlo: para ver lo que ya preparaste, usa git diff --staged. Regla práctica: antes del add, revisa con git diff; después del add y antes del commit, revisa con git diff --staged.

Invertir el orden de los commits al comparar (práctico). Qué pasa: corres git diff <nuevo> <viejo> en vez de <viejo> <nuevo>, y el diff te muestra todo al revés —lo que agregaste aparece con - (quitado) y lo que quitaste con +—, lo que confunde por completo la lectura. Por qué pasa: es fácil olvidar cuál folio va primero. Cómo detectarlo: si un cambio que sabes que fue una adición aparece marcado como quitado, invertiste el orden. Cómo corregirlo: recuerda la regla —git diff te muestra cómo pasar del primero al segundo, así que el punto de partida (lo viejo) va primero y el destino (lo nuevo) va segundo—. Menos siempre es el primero que nombraste; más siempre es el segundo.

Diffear un JSON minificado y rendirse (práctico). Qué pasa: tu workflow está exportado en una sola línea, git diff muestra dos muros de texto idénticos a la vista, y concluyes que Git no sirve para workflows. Por qué pasa: Git trabaja por líneas y un JSON de una línea le impide mostrar el cambio interno. No es una falla de Git; es el formato del archivo. Cómo detectarlo: si tu diff es siempre @@ -1 +1 @@ seguido de dos líneas enormes, tu JSON está minificado. Cómo corregirlo: para hoy, exporta el workflow con la opción de descargar desde el editor, que produce JSON con formato multilínea y ya se diffea razonablemente. La solución completa —normalizar el JSON para que siempre salga limpio y ordenado— es el Módulo 3. No te rindas con Git; el problema es el formato del archivo, y tiene arreglo.

Ejercicios

Ejercicio 1 — Lee un diff a mano. Sin correr nada, lee este diff de order-triage y responde: (a) ¿qué nodo se tocó?, (b) ¿qué parámetro cambió y de qué valor a qué valor?, (c) ¿cuál de las tres zonas de cambio, si hay más de una, es ruido y cuál es real?

@@ -5,7 +5,7 @@
   "name": "order-triage",
-  "versionId": "11111111-aaaa-bbbb-cccc-222222222222",
+  "versionId": "99999999-dddd-eeee-ffff-333333333333",
   "nodes": [
@@ -60,7 +60,7 @@
       "parameters": {
         "method": "GET",
-        "url": "https://crm.cumbre.example/api/customers",
+        "url": "https://crm-staging.cumbre.example/api/customers",
         "options": {
       },
       "name": "Lookup Customer in CRM",
Ver solución

(a) El nodo Lookup Customer in CRM —el HTTP Request que consulta el CRM—. Lo sabes por la línea de contexto "name": "Lookup Customer in CRM" justo debajo del segundo bloque de cambio.

(b) El parámetro url cambió de https://crm.cumbre.example/api/customers a https://crm-staging.cumbre.example/api/customers. Es decir, la consulta al CRM ahora apunta al servidor de staging en lugar del de producción.

(c) Hay dos zonas de cambio. La primera (versionId) es ruido: es un metadato que n8n cambia solo al guardar. La segunda (la url) es el cambio real, y además es exactamente el tipo de cambio que causó el "martes malo" de Cumbre en la lección 1 —apuntar el CRM a staging, que no tiene los datos de los clientes mayoristas—.

Por qué funciona: este ejercicio es leer a través del ruido en estado puro. Aplicaste la regla 1 (saltar versionId) y la regla 4 (detenerte en parameters) sin que te las dictara nadie. Y de paso viste un diff que cuenta una historia con consecuencias: leer bien este diff, en la vida real, es lo que te deja diagnosticar un incidente en treinta segundos.

Ejercicio 2 — Elige el comando correcto. Para cada situación, di cuál de las formas de git diff usarías: git diff, git diff --staged, o git diff <commit> <commit>.

(a) Acabas de editar order-triage.json y quieres revisar qué tocaste antes de preparar nada. (b) Ya hiciste git add y quieres revisar exactamente lo que va a entrar en tu próximo commit. (c) Quieres saber qué cambió entre la versión de tu workflow de hace tres commits y la de ahora.

Ver solución

(a) git diff a secas. Compara tu árbol de trabajo contra el área de preparación, así que te muestra lo que cambiaste y aún no has preparado.

(b) git diff --staged. Compara el área de preparación contra el último commit, que es precisamente lo que entraría en tu próximo commit. Es la revisión de "última mirada antes de guardar".

(c) git diff <commit-viejo> <commit-nuevo>, usando los folios (por ejemplo git diff c08b4a2 HEAD, donde HEAD es "ahora"). Es la única de las tres que viaja por el historial comparando dos fotos guardadas.

Por qué funciona: las tres formas mapean a las tres zonas de la lección 3. (a) trabajo contra preparación, (b) preparación contra historial, (c) historial contra historial. Cuando tengas clara esa correspondencia, elegir el comando deja de ser memoria y pasa a ser deducción: "¿qué dos zonas quiero comparar?".

Ejercicio 3 — Distingue lo real del ruido. Te dan este diff de order-triage con cuatro zonas de cambio. Clasifica cada una como "cambio real de lógica" o "ruido de la plataforma", y para las reales di qué nodo y qué parámetro tocan.

@@ -4,7 +4,7 @@
-  "versionId": "aaaa-1111",
+  "versionId": "bbbb-2222",
@@ -30,7 +30,7 @@
       "parameters": {
-        "path": "order-triage",
+        "path": "order-intake",
       "name": "Receive Order",
@@ -52,7 +52,7 @@
       "typeVersion": 2,
-      "position": [-40, 320],
+      "position": [-40, 288],
       "name": "Receive Order",
@@ -78,7 +78,7 @@
       "parameters": {
         "options": {
-          "timeout": 5000
+          "timeout": 15000
         },
       "name": "Lookup Customer in CRM",
Ver solución
  • Zona 1 (versionId): ruido. Metadato de la plataforma.
  • Zona 2 (path): cambio real. Toca el nodo Receive Order (el Webhook), y cambia su path de order-triage a order-intake. Ojo: este es un cambio con consecuencias —la URL del webhook cambió, así que quien mande pedidos a la dirección vieja va a fallar—. Un diff así merece una nota de commit clara.
  • Zona 3 (position): ruido. El nodo Receive Order se movió en el lienzo (de 320 a 288 en el eje vertical); no cambia nada de lo que hace.
  • Zona 4 (timeout): cambio real. Toca el nodo Lookup Customer in CRM y sube su timeout de 5000 a 15000 milisegundos.

De cuatro zonas, dos son ruido y dos son reales. Y las dos reales son de naturaleza muy distinta: la del timeout es un ajuste inofensivo; la del path puede romper la entrada de pedidos. Leer el diff no es solo separar real de ruido, sino calibrar el riesgo de cada cambio real.

Por qué funciona: este es el ejercicio central de la lección en versión completa. En un diff de verdad de n8n, real y ruido vienen mezclados, y tu trabajo es filtrarlos con las cuatro reglas y luego juzgar el peso de lo que queda. Esa es, literalmente, la tarea de quien revisa cambios antes de aprobarlos —lo que vas a hacer con ramas en la lección 5 y con cambios de equipo en la 6—.

Resumen y siguiente paso

En esta lección aprendiste a leer un diff, que es la habilidad que convierte a Git de una caja de versiones en una herramienta para entender la evolución de tu workflow. Viste qué es un diff —una comparación línea por línea, como el control de cambios de un procesador de texto— y su anatomía: el título, los dos lados (menos es lo viejo, más es lo nuevo), los encabezados de bloque @@ que marcan las zonas de cambio, y las líneas de contexto, quitadas y agregadas. Manejaste las tres formas de git diff: a secas para lo que cambiaste sin preparar, --staged para lo que vas a guardar, y entre dos folios para comparar cualquier par de fotos del historial. Y sobre order-triage leíste un cambio real —una categoría agregada al clasificador— identificando el nodo por su línea name y el parámetro por el par menos/más.

Sobre todo, enfrentaste la realidad incómoda del JSON de n8n: en una sola línea, el diff es ilegible; multilínea, viene con ruido de versionId, posiciones del lienzo y pinData. Y aprendiste a leer a través de ese ruido con cuatro reglas —saltar metadatos, saltar posiciones, saltar datos fijados, detenerte en los parameters—, sabiendo que el Módulo 3 lo resuelve de raíz con la normalización.

Antes de avanzar a la lección 5 deberías poder: leer un diff cualquiera y decir qué se quitó y qué se agregó; elegir entre git diff, git diff --staged y git diff <commit> <commit> según qué quieras comparar; y ante un diff ruidoso de n8n, separar el cambio real del metadato en menos de un minuto.

Hasta aquí, todo tu trabajo ha vivido en una sola línea de tiempo: main, con una foto tras otra. Eso funciona mientras haces un cambio a la vez y estás seguro de él. Pero, ¿qué pasa cuando quieres probar una idea sin arriesgar la versión que funciona? ¿Cuando quieres experimentar con esa categoría wholesale sin que el order-triage bueno deje de estar disponible por si el experimento sale mal? Para eso existen las ramas, y son el tema de la lección 5. Vas a aprender a abrir una línea de trabajo paralela, cambiar en ella con toda tranquilidad, comparar —con los diffs que acabas de dominar— y, si te convence, fusionar de vuelta a main. Es la técnica que le devuelve a un equipo la libertad de mejorar sin miedo.

Recursos

← Anterior3. Staging y commits: fotos de tu workflowSiguiente →5. Ramas para cambiar sin miedo