5. Ramas para cambiar sin miedo

Descripción

Al terminar esta lección vas a poder experimentar con tu workflow sin arriesgar la versión que funciona. Vas a saber qué es una rama —una línea de trabajo paralela— y qué es HEAD, vas a manejar git branch y git switch para crear ramas y moverte entre ellas, vas a conocer un modelo simple de ramas pensado para workflows (main como la versión lista para producción y ramas de feature para lo que estás probando), y vas a fusionar tu trabajo de vuelta con git merge, incluyendo qué pasa —y qué hacer— cuando aparece un conflicto en el JSON.

Esto importa porque es lo que le devuelve a un equipo la libertad de mejorar. Recuerda el segundo costo del "martes malo" de Cumbre en la lección 1: después de un susto, la gente deja de tocar el workflow por miedo a romperlo. Las ramas disuelven ese miedo. Te dejan probar una idea —una categoría nueva, un nodo distinto, una lógica de enrutamiento diferente— en un espacio aparte donde, si sale mal, no pasó nada: la versión buena sigue intacta, esperándote. Es la diferencia entre experimentar sobre una copia y experimentar sobre el original.

Conexión con el módulo: hasta ahora todo tu trabajo vivió en una sola línea de tiempo, main, una foto tras otra. Esta lección abre una segunda dimensión: líneas paralelas. Vas a usar los diffs de la lección 4 para revisar qué hiciste en tu rama antes de fusionarla, y las ramas que aprendas aquí son la base de dos cosas que vienen: el trabajo compartido en GitHub (lección 6), donde cada persona trabaja en su rama, y la iteración en tres ramas distintas que te pide el proyecto de la lección 8. Fusionar y, cuando toca, revertir (lección 7) completan el ciclo.

Qué es, exactamente, una rama

La palabra "rama" ya trae una buena imagen: la de un árbol. Un tronco que en algún punto se divide en dos ramas que crecen por separado. En Git es casi literal: tu historial es el tronco, y una rama es una línea de desarrollo que se separa para crecer aparte, sin afectar al tronco.

Pero hay una definición más precisa, y vale la pena tenerla porque desactiva la idea de que una rama es algo pesado o complicado. Una rama, en Git, es simplemente un puntero móvil a un commit. Nada más. Es una etiqueta con un nombre —main, add-priority-routing— que apunta a una foto de tu historial, y que se mueve sola hacia adelante cada vez que haces un commit nuevo.

Piénsalo con un marcapáginas. Un libro es tu historial de commits, página tras página. main es un marcapáginas que dice "voy por aquí". Cuando lees una página más —haces un commit—, mueves el marcapáginas a la nueva página. Crear una rama es poner un segundo marcapáginas en la misma página, con otro nombre. A partir de ese momento tienes dos marcadores; puedes avanzar uno sin mover el otro. Eso es una rama: un marcapáginas independiente que avanza a su propio ritmo.

Por eso las ramas en Git son tan livianas y tan rápidas. No copian tu proyecto, no duplican archivos, no ocupan espacio de verdad. Crear una rama es poner una etiqueta nueva que apunta al commit donde estás. Toma una fracción de segundo. En otros sistemas de control de versiones, "ramificar" era una operación pesada que la gente evitaba; en Git es tan barato que ramificar para cualquier experimento es lo normal, no la excepción.

HEAD: dónde estás parado

Para entender las ramas necesitas un concepto más, que ya asomó en la lección 3: HEAD. HEAD es el puntero que indica en qué rama estás parado ahora mismo. Si las ramas son marcapáginas, HEAD es la flecha que dice "el marcapáginas que estás usando en este momento es este". Cuando git status te dice On branch main, te está diciendo que HEAD apunta a main. Cuando cambias de rama, lo que se mueve es HEAD: apunta ahora a la otra rama, y tus archivos en la carpeta cambian para reflejar el estado de esa rama.

Esta es la parte que sorprende la primera vez: cambiar de rama cambia los archivos de tu carpeta. Si estás en main con la versión de dos categorías, y saltas a una rama donde agregaste una tercera, tu order-triage.json en la carpeta cambia solo para mostrar la versión de esa rama. No es magia ni riesgo: Git guarda ambos estados en el historial y te muestra el de la rama donde estás parado. Cuando vuelvas a main, el archivo vuelve a la versión de main. Es como girar el marcapáginas del libro: la página que ves es la del marcador que estás usando.

git branch y git switch: crear y moverse

Dos comandos hacen casi todo el trabajo con ramas. Antes conviene ver dónde estás.

Para listar tus ramas y ver en cuál estás:

git branch

Qué esperar, en un repositorio que hasta ahora solo ha usado main:

* main

El asterisco * marca la rama en la que estás parado —donde apunta HEAD—. Con una sola rama, no hay mucho que ver; el asterisco cobra sentido cuando hay varias.

Para crear una rama nueva y moverte a ella en un solo paso, se usa git switch con la opción -c (de create, crear):

git switch -c add-priority-routing

Qué esperar:

Switched to a new branch 'add-priority-routing'

Acabas de hacer dos cosas: creaste una rama llamada add-priority-routing que apunta al mismo commit donde estabas, y moviste HEAD hacia ella. Ahora estás parado en la rama nueva. Confírmalo:

git branch

* add-priority-routing
  main

El asterisco se movió: ahora estás en add-priority-routing. Y fíjate en algo importante: main sigue ahí, intacta, apuntando a donde estaba. No le pasó nada. Tienes dos marcapáginas en la misma página; a partir de aquí puedes avanzar uno sin tocar el otro.

Para moverte entre ramas que ya existen, es git switch sin el -c:

git switch main

Switched to branch 'main'

Y para volver a la de feature, git switch add-priority-routing. Sencillo: -c para crear y saltar, sin -c para saltar a una que ya existe.

Una nota sobre git checkout. Si buscas ayuda en internet, vas a ver muchísimos tutoriales que usan git checkout -b nombre para crear ramas y git checkout nombre para moverte. Hacen lo mismo que git switch. La razón de la diferencia es histórica: git checkout es un comando viejo que hacía demasiadas cosas distintas —cambiar de rama, restaurar archivos, y más— y eso lo hacía confuso y hasta peligroso. En 2019, Git introdujo dos comandos nuevos que reparten esas tareas: git switch para moverse entre ramas y git restore para restaurar archivos. Son más claros y menos propensos a errores, así que en esta guía usamos switch. Si ves checkout en otro lado, ya sabes que es lo mismo con el nombre viejo.

Un modelo simple de ramas para workflows

Con la mecánica clara, la pregunta real es cómo usar las ramas en el día a día. Hay estrategias de branching muy elaboradas para equipos grandes de desarrollo de software —con nombres, reglas y diagramas—, y son justo el tipo de Git avanzado que esta guía deja fuera a propósito. Para el ciclo de vida de un workflow, alcanza con un modelo de dos niveles, y es este:

main es la versión buena, la que está lista para producción. La regla de oro es: main siempre funciona. Lo que esté en main es lo que podrías promover a producción sin sudar. No experimentas directamente sobre main; la tratas como sagrada.

Cada cambio o experimento vive en su propia rama de feature. Cuando vas a tocar algo —agregar una categoría, cambiar el enrutamiento, probar un nodo nuevo—, creas una rama con un nombre que describe el cambio: add-priority-routing, try-urgent-category, fix-crm-timeout. Trabajas ahí con toda tranquilidad, haces los commits que necesites, y solo cuando el cambio está probado y te convence, lo fusionas de vuelta a main.

Por qué este modelo funciona tan bien para workflows: te da un lugar seguro para experimentar. Si la rama try-urgent-category resulta ser una mala idea, la borras y main nunca se enteró. Si resulta buena, la fusionas y main la absorbe. En ningún momento la versión que corre en producción estuvo en riesgo. Es la libertad de probar sin miedo, con una red debajo.

Una convención práctica para los nombres de rama, igual que con las notas de commit: en inglés, en minúsculas, con guiones, y describiendo el cambio con un verbo. add-priority-routing se lee bien; mis-cambios o prueba2 no le dicen nada a nadie. El nombre de la rama es, como el mensaje de commit, un mensaje para tu equipo y para tu yo del futuro.

Ejemplo trabajado: probar una idea en una rama y fusionarla

Vamos a recorrer el ciclo completo: crear una rama, cambiar order-triage en ella, revisar el cambio con un diff, volver a main y fusionar. La idea que vamos a probar: hacer que order-triage, después de clasificar, enrute los pedidos priority a un paso distinto —agregando un nodo de ruteo—.

Paso 1 — Parte de main limpia. Confirma dónde estás y que no hay cambios sueltos:

git status

Debe decir On branch main y nothing to commit, working tree clean. Empezar limpio evita arrastrar cambios a medias a la rama nueva.

Paso 2 — Crea la rama del experimento y muévete a ella.

git switch -c add-priority-routing

Switched to a new branch 'add-priority-routing'

Estás en tierra segura para experimentar. Nada de lo que hagas aquí toca main.

Paso 3 — Haz el cambio en n8n. Abre order-triage, agrega el nodo de enrutamiento para los pedidos priority (por ejemplo un nodo Switch que dirija según la categoría), conéctalo, guarda y exporta. Reemplaza tu order-triage.json con la versión nueva.

Paso 4 — Revisa qué cambiaste, con lo que aprendiste en la lección 4.

git diff

Lee el diff aplicando las cuatro reglas de leer a través del ruido: salta el versionId y las posiciones, y detente en los parameters y los nodos nuevos. Deberías ver el nodo de enrutamiento agregado. Revisar antes de guardar es un buen hábito: te confirma que el cambio es el que querías y solo ese.

Paso 5 — Guarda el cambio en la rama.

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

[add-priority-routing d4e5f6a] Add priority routing after classification
 1 file changed, 14 insertions(+), 2 deletions(-)

Fíjate en el nombre entre corchetes: [add-priority-routing ...]. El commit se guardó en tu rama de feature, no en main. Tu marcapáginas de feature avanzó; el de main sigue quieto.

Paso 6 — Comprueba que main no se enteró. Vuelve a main y mira el archivo:

git switch main

Switched to branch 'main'

Ahora abre tu order-triage.json en la carpeta —o míralo en n8n importándolo—. El nodo de enrutamiento no está. Esto es lo que prometí que sorprendería: al cambiar de rama, el archivo en tu carpeta volvió a la versión de main, la de antes del experimento. Tu trabajo no se perdió: sigue guardado en la rama add-priority-routing, esperando. Simplemente no está en main. Confírmalo con el historial:

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

El commit Add priority routing no aparece, porque no está en main. HEAD apunta a main, y main no tiene ese commit. Todo en orden.

Paso 7 — Decide y fusiona. Supón que probaste el enrutamiento, funciona y te convence. Es hora de traerlo a main. Estando parado en main (que es donde quieres que llegue el cambio), corre:

git merge add-priority-routing

Qué esperar:

Updating a91c3f8..d4e5f6a
Fast-forward
 order-triage.json | 16 +++++++++++++---
 1 file changed, 14 insertions(+), 2 deletions(-)

Léelo: main se actualizó desde el commit a91c3f8 hasta el d4e5f6a —el de tu rama—. La palabra Fast-forward merece una explicación, porque la vas a ver seguido. Significa que main no se había movido desde que creaste la rama, así que Git no tuvo que "combinar" dos líneas divergentes: simplemente adelantó el marcapáginas de main hasta alcanzar el de tu rama. Como avanzar el marcapáginas del tronco hasta la página donde ya estaba el de la rama. Es la fusión más limpia posible.

Ahora git log --oneline en main sí muestra tu commit:

d4e5f6a (HEAD -> main, add-priority-routing) Add priority routing after classification
a91c3f8 Add wholesale category to the order classifier
3e5d720 Widen CRM lookup timeout to 15 seconds
c08b4a2 Add order-triage workflow

main absorbió el trabajo. Fíjate que ahora main y add-priority-routing apuntan al mismo commit —los dos marcapáginas están en la misma página otra vez, la nueva—.

Paso 8 — Limpia la rama. Como ya fusionaste el trabajo, la rama de feature cumplió su función. Puedes borrarla para no acumular ramas viejas:

git branch -d add-priority-routing

Deleted branch add-priority-routing (was d4e5f6a).

No perdiste nada: el commit vive en main. Borraste el marcapáginas, no las páginas. La -d (de delete) solo borra la rama si ya está fusionada; si intentaras borrar una rama con trabajo sin fusionar, Git te frenaría para protegerte —habría que usar -D mayúscula para forzar, y ese es un comando que conviene pensar dos veces—.

Ese es el ciclo completo de una rama: crear, trabajar, revisar, fusionar, limpiar. Lo vas a repetir por cada cambio que valga la pena aislar.

Cuando quieres tirar el experimento

No todo experimento sale bien, y esa es justamente la gracia de las ramas. Supón que la rama try-urgent-category resultó una mala idea: la categoría "urgent" confundía al clasificador. No quieres fusionarla. ¿Qué haces? Nada especial: simplemente vuelves a main y borras la rama.

git switch main
git branch -D try-urgent-category

Aquí sí es -D mayúscula, porque la rama tiene trabajo que no fusionaste y quieres descartarlo a propósito. Git te obliga a usar la mayúscula como un "¿estás seguro?" —descartar trabajo no fusionado es irreversible por las vías normales—. Después de esto, main está exactamente como antes del experimento, como si nunca hubiera pasado. Ese es el regalo de las ramas: los experimentos fallidos no dejan cicatriz. Probaste, no funcionó, lo tiraste, y tu versión buena nunca corrió peligro.

Fusionar cuando las líneas divergen: los conflictos

El Fast-forward del ejemplo fue el caso fácil, porque main no se movió mientras tú trabajabas en tu rama. En el trabajo real —sobre todo en equipo, que es la lección 6— a veces main sí avanza mientras tú estás en tu rama: alguien más fusionó un cambio. Entonces las dos líneas divergieron, y fusionarlas requiere combinarlas de verdad.

La mayoría de las veces, Git combina las dos líneas solo, sin que hagas nada: si los cambios tocaron partes distintas del archivo, los une automáticamente y crea un commit especial llamado merge commit que tiene dos padres. Pero cuando los dos lados cambiaron la misma línea de forma distinta, Git no puede adivinar cuál gana. Eso es un conflicto de fusión, y Git se detiene y te pide que lo resuelvas tú.

Un conflicto se ve así dentro del archivo. Git marca la zona en disputa con unas líneas especiales:

<<<<<<< HEAD
        "text": "=Classify this order into one of: standard, priority, wholesale.",
=======
        "text": "=Classify this order into one of: standard, priority, urgent.",
>>>>>>> try-urgent-category

Léelo así: entre <<<<<<< HEAD y ======= está tu versión (la de la rama donde estás parado, main); entre ======= y >>>>>>> try-urgent-category está la versión de la otra rama. Git te está diciendo "las dos ramas cambiaron esta línea; dime con cuál me quedo". Resolver el conflicto es editar el archivo para dejar la versión correcta —quizás una de las dos, quizás una combinación de ambas— y borrar las tres líneas de marcadores (<<<<<<<, =======, >>>>>>>). Luego haces git add del archivo resuelto y git commit para cerrar la fusión.

Ahora, la honestidad de esta lección: los conflictos en el JSON de un workflow de n8n son especialmente incómodos. Por el ruido que ya conoces —posiciones, versionId, todo en la misma estructura anidada— un conflicto puede aparecer en zonas que ni siquiera son lógica real, y editar JSON a mano, con sus llaves y comas, es delicado: una coma de más y el archivo deja de ser válido, y n8n no lo podrá importar.

Por eso, para workflows, muchas veces la salida más práctica ante un conflicto no es editar el JSON a mano, sino resolverlo desde n8n: decides cuál es la versión correcta del workflow, la reconstruyes o la eliges en el editor, la exportas limpia, y con ese archivo bueno reemplazas el conflictivo. Es menos elegante que editar el diff, pero para un JSON anidado y ruidoso suele ser más seguro. Y —lo anuncio sin resolverlo— el Módulo 3, al normalizar el JSON, hace que los conflictos sean muchísimo más raros y más legibles, porque elimina el ruido que los provoca y los agranda. Por ahora, la regla es: no entres en pánico ante los marcadores <<<<<<<; identifica los dos lados, quédate con el correcto, borra los marcadores, y si el JSON se ve enredado, prefiere reemplazarlo con una exportación limpia desde n8n.

Ver el mapa de tus ramas

Cuando tienes varias ramas conviviendo, ayuda ver el árbol completo de un vistazo en vez de imaginarlo. Git puede dibujarte el historial con las ramas como líneas, directamente en la terminal:

# --all: todas las ramas, no solo la actual.
# --graph: dibuja las líneas de las ramas a la izquierda.
git log --oneline --all --graph

Qué esperar, con main y una rama de feature que todavía no fusionaste:

* 8b1f0c2 (add-priority-routing) Add priority routing after classification
| * 2d9a4e7 (try-urgent-category) Try an urgent category in the classifier
|/
* a91c3f8 (HEAD -> main) Add wholesale category to the order classifier
* 3e5d720 Widen CRM lookup timeout to 15 seconds
* c08b4a2 Add order-triage workflow

Léelo de abajo hacia arriba. El tronco común son los tres commits de abajo, en main. En a91c3f8 el árbol se bifurca: de ahí salen dos ramas, add-priority-routing y try-urgent-category, cada una con su propio commit sin fusionar. Las líneas y la barra |/ a la izquierda dibujan esa bifurcación. Es la misma imagen del árbol con la que abrimos la lección, pero real y generada por Git a partir de tu historia. Cuando te pierdas entre ramas —y al principio pasa— este comando te reorienta en un segundo: te muestra dónde se separó cada línea y qué falta por fusionar.

Es una vista de solo lectura: no cambia nada, solo dibuja. Úsala sin miedo cada vez que quieras un mapa de por dónde va tu trabajo.

Errores comunes

Experimentar directamente sobre main (conceptual). Qué pasa: se hace un cambio arriesgado sin crear una rama primero, y si sale mal, la versión buena quedó contaminada y hay que revertir a mano. Por qué pasa: crear la rama se siente como un paso de más cuando "solo voy a probar algo rápido". Cómo detectarlo: si git status dice On branch main justo antes de un cambio experimental, estás a punto de cometerlo. Cómo corregirlo: adopta el reflejo de crear una rama antes de cualquier cambio que no estés seguro de querer conservar. Es un git switch -c nombre de dos segundos que te compra la tranquilidad de que main siempre funciona. La regla de oro del modelo: no experimentes sobre lo sagrado.

Perder de vista en qué rama estás (práctico). Qué pasa: crees que estás en tu rama de feature pero estás en main, o al revés, y terminas haciendo commits en el lugar equivocado —un experimento a medias aterriza en main, o un cambio que debía ir a main queda atrapado en una rama que luego borras—. Por qué pasa: la rama actual no está siempre a la vista, y es fácil olvidarla tras un rato de trabajo. Cómo detectarlo: git status te dice la rama en su primera línea (On branch ...), y git branch te la marca con el asterisco. Cómo corregirlo: haz de git status tu primer comando siempre, antes de cambiar o guardar nada. Muchos automatizadores configuran su terminal para que muestre la rama actual en el prompt, de modo que siempre esté a la vista; es un ajuste que vale la pena cuando ya te sientas cómodo.

Intentar cambiar de rama con cambios sin guardar (práctico). Qué pasa: tienes cambios sueltos en el árbol de trabajo, intentas git switch a otra rama, y Git te frena con un mensaje diciendo que tus cambios locales se perderían. Por qué pasa: cambiar de rama reescribe los archivos de tu carpeta a la versión de la otra rama, y Git no quiere pisar tu trabajo sin guardar. Cómo detectarlo: si git switch falla mencionando "your local changes would be overwritten" o "commit your changes", es esto. Cómo corregirlo: decide qué hacer con esos cambios antes de saltar —lo más común es hacerles un commit en la rama actual (git add + git commit) y luego cambiar tranquilo—. Si el cambio no lo quieres, puedes descartarlo con git restore. La lección: termina o guarda lo que estás haciendo antes de cambiar de rama.

Entrar en pánico ante un conflicto de fusión (conceptual). Qué pasa: aparece un git merge con conflictos, se ven los marcadores <<<<<<< en el archivo, y la reacción es cerrar todo o creer que se rompió el repositorio. Por qué pasa: los conflictos se ven aparatosos y el JSON de n8n los hace ver peor. Cómo detectarlo: Git te lo dice claramente —"Automatic merge failed; fix conflicts and then commit the result"— y git status lista los archivos en conflicto. Cómo corregirlo: respira. Un conflicto no rompió nada; Git está esperando tu decisión. Identifica los dos lados (tuyo entre <<<<<<< HEAD y =======, el otro debajo), quédate con el correcto, borra los tres marcadores, y para un workflow enredado prefiere reemplazar el JSON con una exportación limpia de n8n. Luego git add y git commit. Si te arrepientes a mitad y quieres cancelar la fusión por completo, git merge --abort te devuelve al estado de antes de intentarla. Nunca estás atrapado.

Ejercicios

Ejercicio 1 — Recorre el ciclo de una rama. En tu repositorio, crea una rama llamada try-shorter-timeout, muévete a ella, cambia el timeout del CRM en order-triage a 8 segundos, exporta, y haz un commit con la nota Reduce CRM lookup timeout to 8 seconds. Luego vuelve a main, confirma con git log --oneline que ese commit no está en main, y finalmente decide: fusiónalo con git merge si te parece bien, o bórralo con git branch -D si prefieres descartarlo. Anota qué comando usaste en cada paso.

git switch -c try-shorter-timeout
# (haces el cambio en n8n y reemplazas order-triage.json)
git add order-triage.json
git commit -m "Reduce CRM lookup timeout to 8 seconds"
git switch main
git log --oneline           # el commit NO aparece aquí
git merge try-shorter-timeout
git branch -d try-shorter-timeout

Ejercicio 2 — Predice el contenido del archivo. Partiendo de main con la versión de order-triage que tiene dos categorías (standard, priority), haces esto en orden: (1) git switch -c add-third-category, (2) cambias el clasificador a tres categorías y haces commit, (3) git switch main. En este momento, ¿qué categorías tiene el order-triage.json que está en tu carpeta? ¿Y si luego corres git switch add-third-category?

Ejercicio 3 — Resuelve un conflicto a mano. Te toca fusionar y aparece este conflicto en order-triage.json. La rama main cambió el timeout a 15 segundos; la rama fix-crm lo cambió a 20. Después de conversarlo, el equipo decidió que el valor correcto es 20 segundos. Escribe cómo debe quedar la zona del archivo una vez resuelto el conflicto.

        "options": {
<<<<<<< HEAD
          "timeout": 15000
=======
          "timeout": 20000
>>>>>>> fix-crm
        }

        "options": {
          "timeout": 20000
        }

git add order-triage.json
git commit -m "Merge fix-crm: set CRM lookup timeout to 20 seconds"

Resumen y siguiente paso

En esta lección aprendiste a experimentar sin miedo. Entendiste qué es una rama —un puntero móvil a un commit, un segundo marcapáginas que avanza a su ritmo, tan liviano que ramificar para cualquier experimento es lo normal— y qué es HEAD, el puntero que indica en qué rama estás parado y que hace que cambiar de rama reescriba los archivos de tu carpeta a la versión de esa rama. Manejaste git branch para listar, git switch -c para crear y saltar, y git switch para moverte, con la nota de que git checkout es lo mismo con el nombre viejo. Adoptaste un modelo simple para workflows —main siempre funciona, cada cambio en su rama de feature— y recorriste el ciclo completo: crear, cambiar, revisar con un diff, fusionar con git merge (viendo el Fast-forward como la fusión más limpia) y limpiar con git branch -d. Viste cómo tirar un experimento fallido sin dejar cicatriz, y enfrentaste los conflictos de fusión: qué son los marcadores <<<<<<<, cómo resolverlos, y por qué en un JSON de n8n ruidoso muchas veces conviene reemplazar el archivo con una exportación limpia —un problema que el Módulo 3 reduce de raíz—.

Antes de avanzar a la lección 6 deberías poder: crear una rama, hacer un commit en ella y comprobar que main no lo tiene; fusionar una rama de vuelta a main y borrarla; y ante un conflicto, identificar los dos lados y saber que git merge --abort siempre te saca del apuro.

Hasta aquí, todo tu historial —con sus commits y sus ramas— vive en un solo lugar: tu máquina. Si tu disco falla, si cambias de computadora, si otra persona del equipo necesita trabajar sobre order-triage, ese historial encerrado en tu máquina no les sirve de nada. La lección 6 abre la puerta al mundo: vas a subir tu repositorio a GitHub, una copia alojada en internet que respalda todo tu historial y que le da a tu equipo un lugar común para trabajar. Vas a aprender qué es un remoto, a crear un repositorio en GitHub y a sincronizar con git push, git pull y git clone. Y vas a ver por qué GitHub cubre —gratis— eso de "compartir workflows entre usuarios" que la edición Community de n8n no trae de forma nativa. Tus ramas están listas; ahora vamos a darles un hogar compartido.

Recursos

• Branches in a Nutshell — Git Docs — el capítulo del libro oficial que explica las ramas como punteros móviles y HEAD, con diagramas. La base conceptual de esta lección.
• Basic Branching and Merging — Git Docs — el ciclo de crear, trabajar y fusionar ramas, incluyendo el fast-forward y la resolución de conflictos.
• git switch — Git Docs — la referencia del comando moderno para moverse entre ramas, con la opción -c para crear.
• git merge — Git Docs — la referencia de la fusión, incluyendo --abort para cancelar una fusión con conflictos y volver atrás sin daño.
• Source control and environments — n8n Docs — el trasfondo de cómo n8n concibe las ramas y los entornos en su control de versiones nativo; útil para tener presente la frontera Community/Enterprise del Módulo 6.