3. Staging y commits: fotos de tu workflow

Descripción

Al terminar esta lección vas a poder tomar la primera foto de tu workflow y las que sigan: vas a saber qué es exactamente un commit —una foto inmutable de tu proyecto, con nota, autor, fecha y un folio único—, vas a entender por qué guardar en Git son dos pasos y no uno (el área de preparación que apareció en la lección 2), y vas a manejar los cuatro comandos del ciclo diario: git add para preparar, git commit para guardar, git status para saber dónde estás y git log para leer el historial. Además vas a aprender a escribir buenas notas de commit para un workflow, que son las que en el martes malo de Cumbre marcan la diferencia entre saber qué pasó y adivinarlo.

Esto importa porque el commit es la unidad de todo. Cada línea de ese git log que viste en la lección 1 es un commit; cada diff que vas a leer en la lección 4 compara dos commits; cada rama de la lección 5 es una línea de commits; cada rollback de la lección 7 vuelve a un commit. Si dominas cómo se hace y cómo se lee un commit, dominas la columna vertebral de Git. El resto son variaciones sobre esto.

Conexión con el módulo: en la lección 2 dejaste tu order-triage.json como archivo "sin seguimiento" —Git lo veía pero no le llevaba el historial—. Esta lección resuelve ese cabo suelto: vas a incorporarlo al historial con tu primer commit, y después vas a hacer un segundo commit sobre un cambio, para ver el ciclo completo repetirse. Con dos commits ya tienes un historial de verdad, que es justo lo que la lección 4 necesita para poder comparar. Todo lo que sigue en el módulo se apoya en saber hacer commits limpios, así que aquí también vamos con calma.

Qué es, exactamente, un commit

Vamos a definirlo bien, porque es la palabra que más vas a usar de aquí en adelante.

Un commit es una foto de todo tu proyecto en un momento dado, guardada de forma permanente en el historial. "Foto" es la palabra correcta y conviene tomarla en serio: no guarda solo lo que cambió, guarda el estado completo del proyecto en ese instante, de modo que puedas volver exactamente a él cuando quieras. Cada commit lleva cuatro cosas pegadas:

• El contenido: el estado de tus archivos en ese momento.
• Una nota (el mensaje): una frase que tú escribes explicando qué cambió y por qué. Es la etiqueta de la foto.
• El autor y la fecha: quién la tomó y cuándo. Git los pone solo, usando el user.name y el user.email que configuraste en la lección 2.
• Un folio único (el hash): un código que identifica esa foto y ninguna otra, como c08b4a2. Git lo genera; no lo eliges tú.

La palabra clave, la que hay que subrayar, es inmutable. Una vez que tomas la foto, esa foto no cambia jamás. Puedes tomar fotos nuevas encima, puedes volver a una vieja, pero la foto de las 9:12 del martes es para siempre la foto de las 9:12 del martes. Esa permanencia es la base de la confianza en Git: cuando git log te dice que en cierto commit el workflow estaba de cierta forma, no hay ambigüedad posible. La foto es la foto.

Piénsalo como el sistema de guardado de un videojuego, de esos donde puedes crear un punto de guardado antes de una parte difícil. Cada punto guarda el estado completo del juego —tu posición, tu vida, tu inventario— con su nombre y su hora. Si algo sale mal más adelante, cargas un punto anterior y vuelves exactamente a como estaba todo. Un commit es un punto de guardado de tu workflow. Y como en el videojuego, la disciplina de guardar en los momentos correctos, con nombres claros, es lo que te salva cuando las cosas se ponen difíciles.

Por qué guardar son dos pasos: el área de preparación

Aquí viene lo que más sorprende a quien llega de otras herramientas. En Dropbox o en Google Docs, guardar es un solo acto: das a guardar y listo. En Git, tomar una foto son dos pasos: primero preparas lo que va a salir en la foto (git add), y después tomas la foto (git commit). Ese paso intermedio es el área de preparación que conociste en la lección 2, y a mucha gente le parece un rodeo inútil hasta que entiende para qué sirve.

Vuelve a la imagen de la foto de grupo. En una fiesta hay veinte personas moviéndose por la sala —ese es tu árbol de trabajo, todo lo que cambiaste—. Cuando vas a tomar una foto, no sale toda la sala en el encuadre: eliges a quién llamas. "Ustedes cinco, los del cumpleaños, párense aquí." Esa selección es el git add: estás poniendo en el encuadre exactamente lo que quieres que salga. Y recién cuando ya tienes a los correctos en su lugar, disparas la cámara: ese es el git commit.

¿Por qué te dejaría Git elegir en vez de fotografiar todo siempre? Porque en un proyecto real casi nunca todos tus cambios cuentan la misma historia. Imagina que en order-triage ajustaste el tiempo de espera del CRM y además, de paso, cambiaste el nombre de un nodo para que se leyera mejor. Son dos cambios independientes. El área de preparación te deja hacer dos fotos separadas —una "Widen CRM lookup timeout" y otra "Rename classifier node for clarity"— aunque los dos cambios estén en tu carpeta al mismo tiempo. Cada foto cuenta una sola historia, y un historial de fotos que cuentan una sola historia cada una es un historial que se lee. Uno donde cada foto mezcla cinco cambios distintos es un historial inútil.

Al principio esto se siente como un paso de más, y es normal. Con el tiempo se vuelve una ventaja que no querrás soltar: es la diferencia entre un álbum ordenado y un cajón de fotos revueltas. Por ahora, quédate con la mecánica: preparar y luego guardar, add y luego commit.

El ciclo diario: status, add, commit, log

Estos cuatro comandos son el 80% de tu trabajo con Git. Los vas a correr decenas de veces al día. Vamos a verlos en acción sobre order-triage, de principio a fin.

Ejemplo trabajado: tu primer commit

Párate dentro de cumbre-automations (recuerda el reflejo de la lección 2: corre pwd para confirmarlo) con tu order-triage.json adentro.

Paso 1 — Pregunta el estado. Siempre se empieza mirando dónde estás:

git status

Qué esperar. El mismo reporte del final de la lección 2: tu archivo aparece como "sin seguimiento".

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	order-triage.json

nothing added to commit but untracked files present (use "git add" to track)

Fíjate que Git te sugiere, entre paréntesis, el comando exacto que sigue: git add. Vamos a hacerle caso.

Paso 2 — Prepara el archivo (ponlo en el encuadre).

git add order-triage.json

Qué esperar. El silencio del éxito: nada. Pero por dentro pasó algo importante, y git status lo confirma:

git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   order-triage.json

Lee el cambio con cuidado, porque es la señal visual que confirma que la preparación funcionó. Antes decía "Untracked files" (sin seguimiento); ahora dice "Changes to be committed" (cambios listos para guardar), y tu archivo aparece marcado como "new file" (archivo nuevo). Traducido: order-triage.json ya está en el encuadre, esperando el disparo de la cámara. Si mostraras los colores de tu terminal, notarías que pasó de rojo (sin preparar) a verde (preparado). Ese cambio de estado es tu confirmación.

Paso 3 — Toma la foto (haz el commit).

git commit -m "Add order-triage workflow"

Desmenucemos el comando: git commit es "toma la foto"; -m significa "el mensaje va aquí mismo" (de message); y entre comillas va la nota de la foto, en inglés como todo el código y los identificadores del ecosistema. Sin la -m, Git abriría un editor de texto para que escribas la nota ahí —y ahí es donde la gente que dejó Vim como editor se queda atrapada sin saber salir—; con la -m, escribes la nota en la misma línea y te evitas esa ventana.

Qué esperar. Ahora Git sí responde, con el resumen de la foto que acaba de tomar:

[main (root-commit) c08b4a2] Add order-triage workflow
 1 file changed, 128 insertions(+)
 create mode 100644 order-triage.json

Léelo pieza por pieza:

• [main ...]: la foto se guardó en la rama main.
• (root-commit): es el primer commit del repositorio, la raíz del historial. Esta etiqueta solo aparece una vez en la vida de un repo, en la primera foto.
• c08b4a2: el folio único de esta foto. El tuyo va a ser distinto —Git lo calcula a partir del contenido, la fecha y el autor, así que es imposible que coincida con el mío—.
• 1 file changed, 128 insertions(+): un archivo entró, con 128 líneas nuevas. El número de líneas depende de qué tan grande sea tu order-triage.json; el tuyo será otro.

Lo lograste: tu workflow tiene su primera foto en el historial. Ese archivo que en la lección 2 estaba "sin seguimiento" ahora vive en el historial de Git, para siempre, con tu nombre y la fecha de hoy.

Paso 4 — Confirma el estado y lee el historial.

git status

On branch main
nothing to commit, working tree clean

"working tree clean" (árbol de trabajo limpio) es una de las frases más tranquilizadoras de Git: significa que no hay ningún cambio suelto, que todo lo que hay en tu carpeta ya está guardado en el historial. Cuando git status dice esto, estás "al día": puedes cerrar la máquina sin perder nada.

Ahora, el comando para leer las fotos que has tomado:

git log

Qué esperar. El historial completo, con todos los detalles de cada commit:

commit c08b4a2f1e9d3b7a5c2081f4e6d9a0b3c7e12345 (HEAD -> main)
Author: Ana Torres <ana.torres@cumbre.example>
Date:   Tue Jul 14 09:12:33 2026 -0600

    Add order-triage workflow

Aquí ves la foto completa: el folio largo (esos siete caracteres del resumen, c08b4a2, son el principio de este código largo), el autor con el nombre y correo que configuraste, la fecha y hora exactas, y tu nota. Hay una etiqueta nueva que conviene entender: HEAD -> main. HEAD es un concepto simple con nombre intimidante: es, literalmente, "dónde estás parado ahora mismo en el historial". Es la flecha que dice "aquí estoy". En este momento HEAD apunta a main, y main apunta a tu único commit. Cuando en la lección 5 saltes entre ramas, lo que se mueve es HEAD. Por ahora, léelo como "estoy parado sobre esta foto".

Para salir de git log cuando la lista es larga y ocupa toda la pantalla, presiona la tecla q (de quit, salir). Es un tropiezo clásico quedarse atascado ahí sin saber cómo volver a la línea de comandos; la tecla es q.

El segundo commit: el ciclo se repite

Un solo commit no es un historial; es una foto. Vamos por la segunda, para ver el ciclo completo sobre un cambio real.

Paso 5 — Cambia algo en el workflow. En n8n, abre order-triage, entra al nodo HTTP Request que consulta el CRM y sube su tiempo de espera —el timeout— de 5 a 15 segundos, porque el CRM a veces tarda. Guarda, exporta de nuevo el workflow y reemplaza tu order-triage.json con la versión nueva. (No importa si no puedes reproducir el cambio exacto en tu instancia; lo que importa es que el archivo cambie.)

Paso 6 — Mira qué ve Git.

git status

Qué esperar. Ahora el archivo aparece como modificado, no como nuevo:

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working tree)
	modified:   order-triage.json

no changes added to commit but "modified:" present (use "git add" to track)

"Changes not staged for commit" (cambios sin preparar) y "modified" te dicen que Git nota que el archivo cambió respecto de la última foto, pero que ese cambio todavía no está en el encuadre. Fíjate en la segunda sugerencia entre paréntesis: git restore <file> descartaría el cambio y volvería el archivo a como estaba en el último commit. Es tu red de seguridad —si te arrepientes de un cambio antes de guardarlo, esa es la salida—, pero úsala con cuidado, porque descartar es descartar.

Paso 7 — Prepara, revisa y guarda.

git add order-triage.json
git status

Tras el add, git status vuelve a decir "Changes to be committed" con tu archivo en verde, marcado esta vez como modified en lugar de new file. Ahora la foto:

git commit -m "Widen CRM lookup timeout to 15 seconds"

Qué esperar:

[main 3e5d720] Widen CRM lookup timeout to 15 seconds
 1 file changed, 1 insertion(+), 1 deletion(-)

Fíjate en las diferencias con el primer commit. Ya no dice root-commit —no es la primera foto—. Y el resumen de cambios ahora es 1 insertion(+), 1 deletion(-): una línea cambió, lo que en el conteo de Git se ve como una línea vieja quitada y una nueva puesta. (En un JSON de n8n real, un cambio de timeout puede tocar más de una línea; el conteo exacto depende de tu archivo. La lección 4 explica por qué esos números a veces son mayores de lo que esperarías.)

Paso 8 — Lee el historial resumido. Ahora que tienes dos fotos, vale la pena ver la vista compacta:

git log --oneline

Qué esperar. Una línea por commit, con el folio corto y la nota:

3e5d720 (HEAD -> main) Widen CRM lookup timeout to 15 seconds
c08b4a2 Add order-triage workflow

Ese --oneline es la forma en que vas a leer el historial el 90% del tiempo: rápido, panorámico, una foto por renglón. Es exactamente el formato del bloque que viste en la lección 1. Y ahora ya sabes producirlo: cada renglón es un git add seguido de un git commit con una buena nota. Se lee de arriba (lo más nuevo) hacia abajo (lo más viejo), y HEAD -> main marca dónde estás parado.

Cómo escribir una buena nota de commit

Los comandos son la parte fácil. La habilidad que de verdad separa un historial profesional de uno inútil es escribir buenas notas de commit. Vale la pena aprenderla bien, porque un historial con malas notas es casi tan inútil como no tener historial.

Recuerda el martes malo de Cumbre de la lección 1. Cuando los pedidos mayoristas dejaron de enrutarse, lo que salvó al equipo con Git fue poder leer git log y entender qué había pasado ese día. Eso solo funciona si las notas dicen algo. Compara estos dos historiales del mismo trabajo:

Un historial inútil:

a91c3f8 cambios
7b2e105 fix
3e5d720 update
c08b4a2 wip

Un historial que sirve:

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

Los dos representan el mismo trabajo. En el primero, cuando algo se rompa, no tienes idea de qué toca cada commit —"fix" de qué, "update" de qué—. En el segundo, cada nota te dice exactamente qué cambió, y puedes ir directo al commit sospechoso. La diferencia entre los dos es diez segundos de reflexión al momento de guardar. Diez segundos que se pagan multiplicados el día del incidente.

Hay una fórmula sencilla, que es la convención de toda la industria, y la vas a aplicar siempre:

1. Empieza con un verbo en imperativo, en inglés, describiendo qué hace el cambio. Add, Fix, Update, Remove, Rename, Widen. La nota completa un: "Si aplico este commit, va a..." → "...Add the wholesale category". Add wholesale category to the order classifier, no added ni adding. Es una convención, y las convenciones facilitan la lectura porque todos escriben igual.

2. Sé específico sobre el workflow. No Fix bug, sino Fix CRM lookup returning empty for wholesale customers. No Update node, sino Rename classifier node for clarity. La nota tiene que responder, sin abrir el diff, "¿qué parte de qué workflow tocó esto?".

3. Mantén la primera línea corta —una regla habitual es no pasar de unos cincuenta caracteres—. Si necesitas explicar por qué con más detalle (no solo qué), puedes dejar una línea en blanco y escribir un párrafo debajo. Para eso se hace el commit sin -m, dejando que Git abra el editor; la primera línea es el título y el resto es el cuerpo. Para el ciclo de vida de un workflow, la mayoría de las veces una buena primera línea alcanza.

Una guía práctica del contenido: la nota describe el qué y, cuando no es obvio, el por qué; el diff ya muestra el cómo. Widen CRM lookup timeout to 15 seconds dice el qué; si el motivo no fuera evidente, un cuerpo podría añadir "the CRM intermittently takes up to 12s under load". Nunca gastes la nota en describir la mecánica línea por línea: para eso está el git diff de la lección 4.

Qué NO fotografiar: una primera mirada al .gitignore

Hay una cara del área de preparación que conviene conocer desde el primer día: así como eliges qué entra en la foto, a veces necesitas decirle a Git que ciertos archivos nunca deben entrar. Para eso existe un archivo especial llamado .gitignore.

Un .gitignore es un archivo de texto, que vive en la raíz de tu repositorio, donde listas los archivos y carpetas que Git debe ignorar por completo: ni siquiera los va a mostrar como "sin seguimiento", ni te va a dejar agregarlos por accidente. Es la lista de "esto no sale en ninguna foto".

¿Por qué querrías ignorar algo? Por dos motivos principales en el mundo de los workflows. Primero, archivos que se generan solos y no aportan historial: registros temporales, cachés, carpetas de sistema que crea tu editor o tu sistema operativo (el clásico .DS_Store de macOS). Segundo, y mucho más importante, secretos: llaves de API, tokens, contraseñas, archivos de credenciales. Un workflow puede necesitar una llave del CRM para correr, pero esa llave jamás debe entrar al historial de Git —si entra, queda registrada para siempre y cualquiera con acceso al repositorio la ve—.

Un .gitignore básico para cumbre-automations podría verse así:

# Archivos del sistema operativo y del editor
.DS_Store
.vscode/

# Secretos: nunca versionar credenciales
.env
credentials.json
*.key

Cada línea es un patrón de lo que se ignora. .env ignora un archivo con ese nombre; *.key ignora cualquier archivo que termine en .key (el asterisco significa "lo que sea"); .vscode/ ignora una carpeta entera.

Aquí me detengo a propósito, porque separar bien las credenciales de los workflows es un tema que merece su lugar y lo tiene: es una lección entera del Módulo 3. Por ahora quédate con la idea y el hábito: antes de tu primer git add, piensa si hay algún secreto cerca que no deba entrar al historial, y si lo hay, créate un .gitignore que lo excluya. Es una de esas precauciones que cuestan un minuto y evitan un problema serio. El Módulo 3 lo formaliza; esta mención temprana es para que no cometas el error justo hoy, en tus primeros commits.

Errores comunes

Hacer git add . a ciegas (práctico). Qué pasa: en vez de agregar el archivo por su nombre, se usa git add . (el punto significa "todo lo que hay en esta carpeta") por costumbre o por rapidez, y sin querer entran a la foto archivos que no debían —un registro temporal, una carpeta del editor, o peor, un archivo de credenciales—. Por qué pasa: git add . es cómodo y muchos tutoriales lo usan sin advertir el riesgo. Cómo detectarlo: después de un git add ., corre git status y lee la lista de "Changes to be committed" completa antes de hacer el commit; si aparece algo que no reconoces o no querías, es esto. Cómo corregirlo: al principio, agrega los archivos por su nombre (git add order-triage.json), que te obliga a saber qué estás guardando. Cuando sí uses git add ., ten primero un .gitignore que proteja los secretos, y siempre revisa el git status antes de disparar. El área de preparación existe precisamente para revisar; no te saltes la revisión.

Editar y creer que ya quedó guardado, sin hacer commit (práctico). Qué pasa: cambias order-triage.json, haces git add, y das el trabajo por guardado —pero nunca corriste git commit—. El cambio quedó en el área de preparación, no en el historial. Por qué pasa: los dos pasos se confunden fácil al principio; "add" suena a que ya guardaste. Cómo detectarlo: git status te lo dice sin rodeos: si hay algo bajo "Changes to be committed" y git log no muestra ese cambio, está preparado pero no guardado. Cómo corregirlo: recuerda que la foto se toma con commit, no con add. add pone a la gente en el encuadre; commit dispara la cámara. No hay foto hasta el disparo.

Notas de commit vagas (conceptual). Qué pasa: se guardan commits con mensajes como fix, cambios, wip o update, y meses después —o el día del incidente— el historial no dice nada útil. Por qué pasa: al momento de guardar, el cambio está fresco en tu cabeza y sientes que la nota es innecesaria; el problema es que en tres semanas ya no vas a recordar qué era "fix". Cómo detectarlo: lee tu propio git log --oneline y pregúntate si, sin abrir cada commit, sabes qué tocó. Si no, tus notas son vagas. Cómo corregirlo: aplica la fórmula —verbo en imperativo, en inglés, específico sobre el workflow—. Fix CRM lookup returning empty for wholesale customers cuesta veinte segundos más que fix y vale su peso en oro el día que algo se rompa. El commit es un mensaje para tu yo del futuro y para tu equipo; escríbelo pensando en ellos.

Meter demasiados cambios en un solo commit (conceptual). Qué pasa: se trabaja toda la tarde tocando cinco cosas distintas del workflow y al final se guarda todo en un commit llamado Update order-triage. Por qué pasa: es más cómodo guardar todo junto al final que ir haciendo fotos por el camino. Cómo detectarlo: si tu nota de commit necesita la palabra "y" varias veces para describir lo que hiciste ("agregué la categoría y cambié el timeout y renombré un nodo"), son varios commits disfrazados de uno. Cómo corregirlo: usa el área de preparación para separarlos —git add solo lo de un cambio, haz su commit, luego lo del siguiente—, o adopta el hábito de guardar más seguido, cada vez que termines una cosa. Un commit por idea. El día que necesites revertir solo uno de esos cambios (lección 7), vas a agradecer no haberlos amontonado.

Commitear un secreto sin darte cuenta (práctico y serio). Qué pasa: un archivo de credenciales o un .env con una llave de API estaba en la carpeta, se coló en un git add ., y quedó guardado en el historial. Por qué pasa: los secretos suelen vivir junto a los workflows y son fáciles de incluir por descuido. Cómo detectarlo: revisa la lista de "Changes to be committed" antes de cada commit buscando nombres como .env, credentials, key, token, password. Cómo corregirlo: lo mejor es prevenirlo con un .gitignore desde el primer commit, como vimos. Si ya se coló, sacarlo del historial no es tan simple como borrar el archivo —una vez fotografiado, queda en las fotos anteriores— y es un tema que el Módulo 3 trata en serio. La regla de oro: ante la duda, no hagas el commit hasta estar seguro de que no hay secretos en el encuadre.

Ejercicios

Ejercicio 1 — El ciclo completo, de memoria. Sin volver a mirar el ejemplo trabajado, escribe en orden los cuatro comandos que usarías para: revisar el estado de tu repositorio, preparar un archivo modificado llamado order-triage.json, guardarlo con la nota "Fix classifier ignoring the priority channel", y luego confirmar que el commit quedó en el historial. Después córrelos de verdad (haciendo primero un cambio cualquiera al archivo) y verifica que funcionan.

git status
git add order-triage.json
git commit -m "Fix classifier ignoring the priority channel"
git log --oneline

Ejercicio 2 — Juzga las notas. Para cada una de estas notas de commit, di si es buena o mala y, si es mala, reescríbela. El contexto es que en cada caso se tocó el workflow order-triage.

(a) update (b) Add retry logic to the CRM lookup node (c) arreglé el bug (d) Rename "Classify" node to "Classify Order" for clarity (e) changes to webhook and classifier and http node

Ejercicio 3 — Predice el estado. Partiendo de un repositorio con el árbol de trabajo limpio (nothing to commit, working tree clean), predice qué reportará git status después de cada una de estas tres secuencias, por separado. Luego verifícalo.

(a) Modificas order-triage.json y no haces nada más. (b) Modificas order-triage.json y corres git add order-triage.json. (c) Modificas order-triage.json, corres git add order-triage.json, y luego modificas order-triage.json otra vez sin volver a hacer git add.

Resumen y siguiente paso

En esta lección tomaste la primera foto de order-triage y las siguientes. Entendiste qué es un commit: una foto inmutable del proyecto, con nota, autor, fecha y un folio único, como un punto de guardado de videojuego al que siempre puedes volver. Viste por qué guardar son dos pasos —el área de preparación que te deja elegir qué entra en cada foto, para que cada commit cuente una sola historia— y manejaste el ciclo diario completo: git status para mirar, git add para preparar, git commit -m para guardar y git log (con su versión --oneline) para leer el historial. Conociste HEAD como "dónde estás parado" y working tree clean como "estás al día". Aprendiste a escribir buenas notas de commit con la fórmula —verbo imperativo en inglés, específico sobre el workflow— y por qué esas notas son las que salvan el día del incidente. Y viste, como primera precaución, el .gitignore para que los secretos nunca entren al historial, un tema que el Módulo 3 desarrolla.

Antes de avanzar a la lección 4 deberías poder: hacer un commit de principio a fin sin mirar la guía; leer un git status y decir en qué zona está cada cambio; leer un git log --oneline y explicar qué es cada parte; y juzgar si una nota de commit es buena o mala.

Ahora tienes dos fotos en el historial: Add order-triage workflow y Widen CRM lookup timeout to 15 seconds. Y con dos fotos aparece una pregunta natural que hasta ahora no podías responder: ¿qué cambió, exactamente, entre una y otra? En la lección 2 subiste un timeout de 5 a 15 segundos, pero el historial solo te dice que "algo" cambió en el archivo. La lección 4 es la que te deja ver el cambio por dentro, línea por línea, con git diff. Y ahí vas a chocar de frente con la realidad incómoda del JSON de n8n: que su formato produce diffs ruidosos, llenos de ruido que no cambió nada real, y vas a aprender a encontrar el cambio de verdad en medio de ese ruido. Esa lección es la bisagra del módulo: es donde Git deja de ser teoría y se vuelve la herramienta que de verdad te deja entender la evolución de un workflow.

Recursos

• Recording Changes to the Repository — Git Docs — el capítulo del libro oficial que cubre add, commit, status y el ciclo completo. La referencia central de esta lección.
• git commit — Git Docs — la página de referencia del comando, con la opción -m y las demás. Útil para cuando quieras escribir mensajes con cuerpo, no solo título.
• git add — Git Docs — la referencia del comando de preparación, incluyendo qué hace el git add . que conviene usar con cuidado.
• How to Write a Git Commit Message — cbea.ms — el artículo de referencia sobre notas de commit, con las reglas del verbo imperativo y del título corto. Escrito para desarrolladores, pero sus reglas aplican igual a un workflow.
• gitignore — Git Docs — la referencia de los patrones del .gitignore, para cuando en el Módulo 3 lo lleves más lejos con las credenciales.