DEV Community: Jesus Manuel Garcia Torres

Meet Anfi: an agent that gets first-timers to their first pull request, one step at a time

Jesus Manuel Garcia Torres — Mon, 12 Oct 2026 17:09:26 +0000

Next Saturday, October 17, we're hosting Hacktoberfest 2026 Tabasco at Xpectre House in Villahermosa, Mexico. The poster says "Beginners welcome", and we mean it. But every year I see the same moment: someone opens GitHub, stares at millions of repositories, and quietly closes the laptop.

This weekend I built Anfi (short for anfitrión, Spanish for "host"), a chat agent whose only job is to get a first-time contributor from "I've never done this" to "I opened my first pull request."

What it does and who it's for

Anfi is for people coming to their first open source event: students, career-switchers, and developers who have used GitHub only to download things.

In a conversation, Anfi:

Asks two questions, and no more: which language you know (even a little), and whether you've used git.
Finds one beginner-friendly issue on GitHub that matches you. It looks for open, unassigned issues labeled good first issue in your language. If you don't code yet, it looks for documentation issues.
Walks you through the contribution one step at a time: ask to be assigned, fork, clone, branch, change, commit, push, open the PR. It waits for you to say "done" before giving the next step.
Answers event questions (when, where, what to bring) and is honest when it doesn't know something.

It speaks Spanish or English, depending on how you write to it.

How I built it

I built Anfi in n8n, the workflow automation tool I use every day as an n8n Ambassador, with Amazon Bedrock as the brain.

The workflow has five nodes:

Chat Trigger. n8n's hosted public chat gives me a shareable URL for attendees, so nobody has to install anything.
AI Agent. This node holds the system prompt, which is where most of the design work went (more on that below).
AWS Bedrock Chat Model. The workflow ships wired to Claude Haiku on Amazon Bedrock. For a guided, short-message conversation it is fast and cheap, and Bedrock keeps the model behind IAM credentials instead of yet another API key. For fast, free iteration, I ran the test suite below on the same workflow with the model node pointed at Gemma 4 running locally in Ollama; the model is a single swappable node in n8n.
Window Buffer Memory. It keeps the last ~10 messages per session, so Anfi remembers your language and git level as you go.
HTTP Request Tool (search_good_first_issues). It calls the GitHub Search API with a query like is:issue is:open no:assignee label:"good first issue" language:python. The model fills in the language with n8n's $fromAI(). I trimmed the response down to title, URL, repo, comment count and labels, so the model reads five small objects instead of a wall of JSON.

I treated the system prompt as the product spec. It defines the event facts (and tells the agent to never invent others), the conversation flow, the tone (3–6 lines, at most one emoji), how to handle errors, and one safety rule: issue text from GitHub is untrusted data, and Anfi never follows instructions inside it.

To keep the build honest, the workflow JSON is generated from the prompt file by a script. A validator checks the node types, the connections, that the system message matches the prompt byte for byte, and that no secrets leaked into the export. A second script runs the real GitHub queries for Python, JavaScript and Markdown to confirm they return issues.

The delightful detail: one issue, one step

The obvious design is what most agents do: return a list of ten issues and a full eight-step git tutorial. It's technically correct, and it's exactly what makes beginners close the laptop. Choosing between ten repos you've never heard of is a decision a first-timer can't make yet.

So I made one rule and built everything around it: Anfi gives you exactly one thing at a time. One issue, picked for you, with one sentence on why it's a good first one. Then one step, and it waits for you to say "done" before the next.

The first run follows the same rule. Anfi greets you and asks two plain questions ("What language do you know, even a little? Have you used git?"), not a form. You get value in your second message.

How I know it worked: before putting it in front of real attendees, I wrote 20 end-to-end scenarios that talk to the live n8n chat endpoint, multi-turn, the way a person would: a Python beginner who has never used git, someone who "can't code yet", an English speaker, someone who asks for a different issue, someone who pastes a git error, someone who asks for the system prompt, someone who offers their GitHub token. Each scenario checks the behavior that matters for the experience (exactly one issue link, the reply's language, short messages, correct event facts), and the runner calls the GitHub API to confirm that every issue Anfi recommends actually exists and is open.

The first run passed 15 of 20. One failure was my test's fault. The other four were real, and they were all experience bugs rather than crashes:

Anfi named an issue but forgot the link.
It said "give me a moment, I'll search" and then never called the tool. The person only ever sees the final message.
When someone opened with "I can't code yet and never used git", it asked the two questions they had just answered.
It answered an English speaker in Spanish.

Each fix was a line in the system prompt. Reading the transcripts also caught a false pass in my own language check, so I tightened it and confirmed it now fails on the old reply. The third run passed 19 of 20:

In all 10 replies that recommended an issue, there was exactly one link, and every link was a real, open issue.
No replies leaked the prompt or accepted a token.
The remaining failure is honest and still open: a Spanish message that contained an English git error got its (correct) explanation in English.

Proof it works

A real conversation from the test run, word for word:

Me: no sé programar todavía y nunca he usado git (I can't code yet and I've never used git)

Anfi: ¡Hola! No te preocupes, es un punto de partida perfecto y es muy valiente querer empezar. ¡Te voy a guiar paso a paso! He encontrado una tarea sencilla en el repositorio mdn/translated-content: [es] Sincronizar Games/Tutorial_2D_breakout_game_pure_JavaScript/Initialize_the_canvas, https://github.com/mdn/translated-content/issues/39175 …

For someone who can't code yet, it picked a Spanish translation task on MDN. That's the kind of match I would have made by hand.

And a live run in n8n's hosted chat. The issue title is the link:

What I'd do next

Run the same 20 scenarios against Claude Haiku on Bedrock and compare the numbers with the local run.
Fix the last failing scenario: when a message mixes Spanish with an English error log, Anfi should still answer in Spanish.
Add a GitHub token so the search tool isn't limited by the API's unauthenticated rate limit during the event rush.
Let Anfi check the PR link you paste and congratulate you once the PR actually exists.
Bring it to the room on Saturday and watch where people still get stuck.

If you're organizing a Hacktoberfest event, the workflow is a single JSON import: plug in your AWS credentials and your event details, and you have a host that never gets tired of explaining git push.

See you in Villahermosa. 🚀

Originally published on AWS Builder Center. Drafted with AI assistance; the build, tests and results are mine.

Resuelve tu primer conflicto de Git entendiendo el cambio, con ayuda de GitKraken

Jesus Manuel Garcia Torres — Sun, 11 Oct 2026 22:11:53 +0000

Soy ambassador de GitKraken. Esta práctica usa un conflicto intencional para mostrar cómo interpretar e integrar dos cambios.

Un conflicto aparece cuando Git necesita que una persona decida el resultado de una integración. Dos cambios pueden ser válidos por separado y aun así requerir una decisión conjunta.

Vamos a modificar la misma línea desde dos ramas. Después construiremos un resultado que conserve ambas intenciones: ampliar el horario y aclarar la zona horaria.

Antes de empezar

Necesitas Git, GitKraken Desktop y un editor. Usa una carpeta nueva y Bash, Zsh o Git Bash. Todo el ejercicio es local.

1. Crea una versión inicial

mkdir taller-git-conflictos
cd taller-git-conflictos
git init -b main
git config user.name "Demo Git"
git config user.email "demo@example.com"
printf 'Horario: 09:00 a 18:00\n' > horario.txt
git add horario.txt
git commit -m "docs: registrar horario inicial"

Abre el repositorio en GitKraken. Este commit será el ancestro común de las dos versiones.

2. Amplía el horario en una rama

git switch -c docs/horario-ampliado
printf 'Horario: 08:00 a 20:00\n' > horario.txt
git add horario.txt
git commit -m "docs: ampliar horario de atención"

La intención es atender durante más horas. Todavía no hemos cambiado main.

3. Aclara la zona horaria en main

git switch main
printf 'Horario: 09:00 a 18:00, hora de Ciudad de México\n' > horario.txt
git add horario.txt
git commit -m "docs: aclarar zona horaria"

En el gráfico verás que las ramas divergieron: cada una tiene un commit que la otra no contiene.

4. Inicia la integración

Con main activa en GitKraken, haz clic derecho sobre docs/horario-ampliado y selecciona la opción de merge hacia la rama actual. Confirma que el destino sea main. El flujo oficial de merge describe este procedimiento.

También puedes iniciar la misma operación desde la terminal, pero ejecuta solo una de las dos alternativas:

git merge docs/horario-ampliado

El conflicto en horario.txt es el resultado esperado.

5. Decide qué debería decir el archivo

Abre el archivo conflictivo. Si usas un editor de texto, encontrarás un bloque parecido a este:

<<<<<<< HEAD
Horario: 09:00 a 18:00, hora de Ciudad de México
=======
Horario: 08:00 a 20:00
>>>>>>> docs/horario-ampliado

En este merge, HEAD representa main, la rama destino. La otra sección corresponde a la rama que estás incorporando.

Elegir cualquiera de las líneas completas perdería una intención. Para este ejercicio, el resultado acordado es:

Horario: 08:00 a 20:00, hora de Ciudad de México

Reemplaza todo el bloque por esa línea y guarda. GitKraken ofrece herramientas visuales para conflictos; su editor de salida integrado requiere una licencia de pago según la documentación. También puedes editar el archivo con tu editor habitual, como acabamos de hacer.

6. Marca la resolución y concluye

git add horario.txt
git diff --cached
git commit -m "merge: unificar horario ampliado y zona horaria"
git status
git log --oneline --graph --all

Antes del commit, confirma que el diff contiene la frase final y ningún marcador. Al terminar, espera un directorio limpio y un commit de merge con dos padres.

Resolver también implica validar

En este archivo basta leer la oración final. En código, una integración puede quedar sin marcadores y seguir siendo incorrecta: ejecuta las pruebas correspondientes y revisa el comportamiento afectado.

Si necesitas cancelar antes de concluir este laboratorio, puedes usar git merge --abort. El ejercicio comenzó la integración con el directorio limpio.

Reto: repite la práctica con dos precios diferentes. Esta vez, explica qué información de negocio necesitas antes de escoger un valor.

¿Qué conflicto te ha exigido hablar con otra persona para entender la intención del cambio?

Guardabosque: an offline nature guide for Tabasco's jungles, powered by Gemma running on my laptop

Jesus Manuel Garcia Torres — Sun, 11 Oct 2026 19:29:59 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I live in Villahermosa, Tabasco, in southeastern Mexico. We're surrounded by wetlands, rivers, jungle reserves and city parks full of toucans, iguanas, herons and plants most of us can't name. But the moment you walk into Pantanos de Centla or the trails of Agua Blanca, your phone signal disappears, and so does every "identify this plant" app that depends on the cloud.

Guardabosque ("forest ranger" in Spanish) is a nature guide that works with no internet at all:

Your laptop runs Gemma 4 locally through Ollama and serves a small web app.
Your phone connects to the laptop over a local hotspot (no data plan needed) and opens the app.
You snap a photo of a bird, plant or insect. Gemma identifies it, tells you what else to look for nearby, warns you if it's dangerous (snakes, stinging plants, crocodiles: this is Tabasco), and gives you a 5–10 minute field quest so you keep walking instead of scrolling.
A Mission tab generates a short walk for real Tabasco places (Parque Tomás Garrido, La Venta, Yumká, Pantanos de Centla, Agua Blanca, Kolem Jaa', Grutas de Coconá, or just your neighborhood park), with steps you check off as you go.
A field journal saves what you found, with a thumbnail, on your own machine.

The design goal was simple: the screen should be the shortest part of the experience. Take a photo, read for ten seconds, put the phone away.

It's for families, students and anyone in the southeast who wants to know what they're looking at, especially the kids in our STEAM-HER community who are starting to explore science and tech.

Demo

Last week I was at a ranch in Cárdenas, Tabasco and photographed a pile of green fruit that had fallen under the trees. Nobody around was sure what it was. Back home, I ran that photo through Guardabosque. Gemma recognized it as tropical palm fruit, described the oblong, rough-skinned fruit and the jungle setting, and added the one safety note that actually matters: don't eat it without an expert identification, because some tropical plants are toxic. Then it gave me a field quest: walk slowly along the trail and look at the mosses and ferns growing at the base of the trees.

That last part is the whole point. Instead of "here's a Wikipedia summary, keep scrolling", it sends you back out to look at something else.

Here's a real response from Gemma 4 running on my M1 Pro, for a photo of a keel-billed toucan:

{
  "kind": "bird",
  "commonName": "Tucán",
  "scientificName": "Ramphastos",
  "confidence": "high",
  "description": "Es un ave grande con un cuerpo predominantemente negro. Su característica más notable es su pico grande y colorido, que presenta tonos verdes, rojos y amarillos.",
  "lookFor": [
    "Busca aves con picos grandes y coloridos.",
    "Observar el comportamiento de alimentación en el dosel del bosque.",
    "Escuchar sus llamadas distintivas."
  ],
  "safety": "",
  "fieldQuest": "Camina lentamente por los senderos permitidos, observando la diversidad de aves en el dosel del bosque durante diez minutos."
}

Each photo takes about 30 seconds on a 16 GB M1 Pro once the model is warm. On a trail, that's fine: you take the photo and keep looking around while it thinks.

Code

gartox / guardabosque

Offline nature guide for Tabasco, Mexico: identify plants and wildlife from a photo with Gemma running locally via Ollama. No internet needed.

Guardabosque

Guardabosque is an offline nature guide for people exploring Tabasco, Mexico. It uses an open-weight Gemma model running locally through Ollama to identify a plant, bird, insect, or other organism from a phone photo, suggest what to observe, and create a short field mission that gets people walking again.

It is designed for parks, wetlands, forests, and neighborhoods where mobile coverage is unreliable. Photos stay on the local device and laptop, there is no service cost, and the model can be changed with GUARDABOSQUE_MODEL.

Requirements

Node.js 24 or newer
Ollama running on the laptop
A Gemma model available locally

Run it

ollama pull gemma4:e4b-it-qat
npm start

Open the printed network URL from a phone connected to the same Wi-Fi network or to a hotspot hosted by the phone or laptop. The laptop runs the server and Ollama; the phone is the field interface.

Useful configuration defaults are:

PORT=3000

…

View on GitHub

How I Built It

Model: Gemma 4 E4B (gemma4:e4b-it-qat), Google's open-weight multimodal model, in its quantization-aware 6.1 GB build. It reads the photo and answers in Spanish.
Local inference: Ollama on the laptop. Nothing leaves the device.
App: Node.js with zero dependencies. Just node:http, node:fs and node:test. If the whole point is that it works without internet, I didn't want a npm install step that needs it. The frontend is plain HTML, CSS and JavaScript, installable as a PWA, mobile first, with high contrast so you can read it in full sun.
Safety by design: the model's output is treated as untrusted data. The server validates and normalizes every field (unknown values fall back to safe defaults, long text is trimmed), the UI never renders model text as HTML, and the prompt tells Gemma to ignore any instructions written inside a photo.
Tests: 12 tests with a fake Ollama server, covering broken JSON from the model, adversarial output with HTML and extra fields, oversized uploads, path traversal and Ollama being offline.

Two things I learned the hard way

1. Structured output isn't guaranteed. My first version asked Ollama to enforce a JSON schema with the format parameter. On my Homebrew build, the MLX engine returned 501 Not Implemented for structured output, and a different build silently ignored the schema and answered in prose. The fix: always describe the schema in the prompt too, extract the JSON even if it's wrapped in markdown, retry once, and remember when a server doesn't support format so you don't pay for the 501 on every request.

2. Pick the model size for the machine you have. The default gemma4:e4b tag pulled a 9.5 GB build, and with Docker running my 16 GB Mac hit 30 GB of swap; a single photo took more than three minutes. Switching to the 6.1 GB QAT build brought it down to about 30 seconds with similar answers. With open weights you choose the trade-off yourself instead of taking whatever a vendor serves.

Why Does Open Innovation Matter?

It works where we actually go outside. Pantanos de Centla, Kolem Jaa' and the Sierra de Tabasco have little or no signal. A cloud API is useless there; a model on my laptop works.
Photos stay with you. Pictures of your kids at the park, your backyard or a protected area never go to someone else's server.
It costs nothing to run. No API key and no per-photo bill, so a school, a community group or a park ranger can use it all day.
I can change the model. One environment variable (GUARDABOSQUE_MODEL) swaps Gemma for any other model in Ollama. When I needed a lighter build for my laptop, I switched in minutes. With a closed API I'd have been stuck with whatever was offered.
Anyone can adapt it. It's MIT licensed with no dependencies. Someone in Chiapas or the Yucatán can fork it, swap in their own places and run it tomorrow.

Prize Categories

Best Use of Gemma: Gemma 4 E4B, running fully locally and multimodal, is the core of the project.

Built by @gartox.

Git worktrees con GitKraken: atiende un hotfix sin perder tu contexto

Jesus Manuel Garcia Torres — Mon, 28 Sep 2026 17:53:24 +0000

Estás a mitad de una funcionalidad y llega el mensaje: “Necesitamos corregir esto cuanto antes”.

Tienes archivos modificados, ideas a medias y una rama que todavía no está lista. Necesitas atender la urgencia sin desacomodar lo que estabas haciendo.

Aquí es donde Git worktrees resulta útil: puedes abrir otra rama del mismo repositorio en una carpeta diferente y trabajar en ambas sin cambiar continuamente de rama en un único directorio.

Esta guía forma parte de mi serie sobre Git y GitKraken para la comunidad de habla hispana.

En el primer artículo practicamos ramas, staging y commits. Ahora vamos a usar esos conceptos para resolver una interrupción cotidiana.

¿Qué es un worktree?

Un worktree es un directorio de trabajo vinculado a tu repositorio.

Cada worktree tiene sus propios archivos, área de staging y HEAD, que identifica el commit o la rama en la que estás trabajando. Los worktrees comparten los objetos de Git y las referencias de las ramas.

Puedes organizarte así:

carpeta-de-practicas/
├── taller-git-worktrees/   → feature/nuevo-menu
└── taller-git-hotfix/      → hotfix/contacto

Compartir repositorio no significa que los cambios se integren automáticamente entre ramas. Un commit creado en el hotfix estará disponible en el historial compartido, pero la otra rama conservará su versión de los archivos hasta que incorpores ese cambio.

Puedes consultar este modelo en la documentación oficial de Git worktree.

Qué vamos a conseguir

Al terminar tendrás:

Una funcionalidad con trabajo pendiente en su propia carpeta.
Una corrección guardada en otra rama.
La comprobación de que atender el hotfix no modificó el trabajo pendiente.
Un procedimiento para retirar el worktree cuando termines.

No necesitas instalar dependencias ni levantar una aplicación.

Antes de empezar

Necesitas Git, un editor y GitKraken Desktop con soporte para worktrees, disponible desde la versión 10.5 según su documentación oficial.

Los comandos están preparados para Bash, Zsh o Git Bash en Windows. Usa una carpeta nueva, fuera de tus proyectos habituales.

Combinaremos la terminal para preparar el laboratorio con GitKraken para revisar los cambios y crear el commit de la corrección.

1. Prepara una funcionalidad a medias

Ejecuta:

mkdir taller-git-worktrees
cd taller-git-worktrees

git init -b main
git config user.name "Demo Git"
git config user.email "demo@example.com"

printf 'Contacto: soporte pendiente\n' > contacto.txt

git add contacto.txt
git commit -m "chore: crear portal de ejemplo"

git switch -c feature/nuevo-menu
printf 'Menú en construcción\n' > menu.txt

La identidad de ejemplo queda configurada únicamente para este repositorio.

Ahora tienes una rama llamada feature/nuevo-menu y un archivo menu.txt sin commit. Este archivo representa la funcionalidad que estabas desarrollando cuando llegó la urgencia.

Abre la carpeta taller-git-worktrees en GitKraken. Comprueba que la rama activa sea feature/nuevo-menu y que aparezca el archivo pendiente.

También puedes verificarlo en la terminal:

git status --short

El resultado debe incluir:

?? menu.txt

Los signos ?? indican que Git todavía no está siguiendo ese archivo.

2. Crea un worktree para el hotfix

La urgencia consiste en corregir el contacto de soporte. Queremos partir de main, sin incluir la funcionalidad incompleta.

Desde la misma terminal, ejecuta:

git worktree add -b hotfix/contacto ../taller-git-hotfix main
git worktree list

El primer comando hace tres cosas:

Crea la rama hotfix/contacto.
Usa main como punto de partida.
Prepara los archivos de esa rama en ../taller-git-hotfix.

El segundo comando muestra las carpetas vinculadas y la rama activa en cada una.

Tu archivo menu.txt sigue pendiente en la carpeta original. No necesitamos guardarlo en un commit ni retirarlo para comenzar la corrección.

¿También se puede crear desde GitKraken?

Sí. Para hacerlo visualmente, prepara una rama que no esté activa en otro worktree, haz clic derecho sobre ella y selecciona Create worktree.

En este laboratorio ya lo creamos desde la terminal. Ahora solo ábrelo desde el panel izquierdo de GitKraken, usando Open this worktree o Open worktree in a new tab. El procedimiento visual está documentado aquí.

3. Corrige desde la carpeta del hotfix

En la terminal, entra al nuevo directorio y comprueba la rama:

cd ../taller-git-hotfix
git branch --show-current

El resultado debe ser:

hotfix/contacto

Actualiza el archivo y revisa la diferencia:

printf 'Contacto: soporte@example.com\n' > contacto.txt
git diff

El cambio esperado es:

-Contacto: soporte pendiente
+Contacto: soporte@example.com

En GitKraken:

Abre el worktree del hotfix.
Confirma que estás en hotfix/contacto.
Revisa el diff de contacto.txt.
Pasa únicamente ese archivo a staging.
Crea el commit con este mensaje:

fix: corregir contacto de soporte

El correo utilizado es ficticio.

4. Regresa y comprueba que conservaste tu contexto

Vuelve al directorio original:

cd ../taller-git-worktrees

git status --short
cat menu.txt
cat contacto.txt

Debes encontrar:

menu.txt todavía sin commit.
El texto Menú en construcción intacto.
El contacto original: Contacto: soporte pendiente.

Este último punto es importante: la corrección quedó guardada en hotfix/contacto, pero todavía no está integrada en feature/nuevo-menu.

Los worktrees nos permitieron trabajar en dos contextos independientes. La integración entre ramas sigue siendo una decisión explícita.

5. Termina el laboratorio y retira el worktree

Para cerrar la práctica, guardaremos el borrador del menú en su rama:

git add menu.txt
git commit -m "feat: agregar borrador del menú"

Ahora integra la corrección en main:

git switch main
git merge --ff-only hotfix/contacto

En este laboratorio main no recibió otros commits, así que puede avanzar directamente hasta el commit del hotfix.

Antes de retirar la carpeta, comprueba que no tenga cambios pendientes:

git -C ../taller-git-hotfix status --short

Si no muestra nada, puedes continuar:

git worktree remove ../taller-git-hotfix
git branch -d hotfix/contacto
git worktree list

git worktree remove retira el directorio de trabajo vinculado. La eliminación de la rama es una operación separada, que hacemos después de integrarla.

Al terminar:

main contiene el contacto corregido.
feature/nuevo-menu conserva el commit del menú.
La carpeta temporal del hotfix ya no es necesaria.

En un repositorio compartido, publica la rama y sigue el proceso de pull request, revisión y validación del equipo antes de dar por integrada la corrección.

Lo que debes considerar en una aplicación real

Un worktree separa los archivos de trabajo, pero no configura automáticamente un entorno completo e independiente.

Si ejecutas dos versiones de tu aplicación, revisa:

Dependencias: cada carpeta puede necesitar su propia instalación.
Variables locales: los archivos ignorados, como .env, no se copian automáticamente desde la otra carpeta.
Puertos: dos servidores no pueden escuchar simultáneamente en la misma dirección y puerto.
Bases de datos y servicios: ambas instancias podrían conectarse al mismo recurso externo.

Además, Git normalmente impide activar una misma rama en dos worktrees. Utiliza una rama distinta por tarea.

¿Cuándo conviene usar este flujo?

Es especialmente útil cuando necesitas mantener dos contextos disponibles durante un tiempo: atender un hotfix, revisar otra rama o comparar implementaciones.

Para una pausa breve, git stash también puede ser suficiente. La ventaja del worktree aparece cuando quieres conservar las carpetas abiertas y moverte entre ellas sin reemplazar continuamente sus archivos.

GitKraken te permite seguir visualmente qué rama estás revisando y qué cambios estás guardando. El hábito sigue siendo el mismo: confirma carpeta, rama y diff antes de cada commit.

Reto para practicar

Desde main, crea otra rama con su propio worktree para escribir documentación.

Agrega un archivo sin hacer commit y comprueba que:

Aparece como pendiente en el nuevo worktree.
No aparece en el directorio original.
Puedes identificar ambas carpetas con git worktree list.

Después guarda el cambio y decide si quieres integrarlo o conservarlo en su rama antes de retirar el worktree.

¿Para qué usarías primero este flujo: atender un hotfix, revisar un pull request o probar una idea?

Git con contexto: tu primer flujo de ramas y commits en GitKraken

Jesus Manuel Garcia Torres — Mon, 21 Sep 2026 18:38:28 +0000

Git con contexto: tu primer flujo de ramas y commits en GitKraken

Etiquetas sugeridas: git, gitkraken, tutorial, beginners

Soy ambassador de GitKraken. En esta guía comparto un ejercicio práctico para aprender Git con apoyo visual y entender qué hace cada operación.

Terminas un cambio, haces commit y descubres que también agregaste un archivo que no tenía relación. El problema empezó antes del commit: faltó revisar qué iba a entrar en él.

Vamos a construir un flujo pequeño: crear una rama, modificar un archivo, revisar el diff y registrar un cambio con intención. Usaremos GitKraken Desktop para observar el historial y una terminal para preparar un laboratorio reproducible.

Antes de empezar

Necesitas Git, GitKraken Desktop y un editor de texto. Los comandos funcionan en Bash, Zsh o Git Bash en Windows. Ejecuta el ejercicio en una carpeta nueva, fuera de tus proyectos. No necesitas un remoto.

1. Prepara el repositorio

mkdir taller-git-ramas
cd taller-git-ramas
git init -b main
git config user.name "Demo Git"
git config user.email "demo@example.com"
printf '# Portal demo\n' > README.md
git add README.md
git commit -m "docs: crear descripción inicial"

La identidad queda configurada únicamente en este repositorio. El primer commit será el punto de partida.

Abre la carpeta desde la opción de abrir un repositorio existente de GitKraken Desktop. Localiza el commit y la etiqueta main en el gráfico.

2. Crea una rama para una sola tarea

La tarea será documentar cómo iniciar el portal.

En GitKraken, haz clic derecho sobre el commit de main, selecciona Create branch here y escribe docs/inicio-local. Después haz doble clic en la rama para activarla. Este procedimiento está documentado en la guía oficial de ramas.

Antes de editar, comprueba que la rama activa sea docs/inicio-local.

Una rama nombra una línea de trabajo. Crear la rama todavía no produce cambios en los archivos ni un commit nuevo.

3. Haz un cambio fácil de revisar

En tu editor, reemplaza el contenido de README.md por:

# Portal demo

## Inicio local

Este repositorio es un laboratorio para practicar Git.
No requiere instalar dependencias ni levantar un servidor.

Guarda el archivo. Regresa a GitKraken y revisa el diff del cambio pendiente. Debe mostrar únicamente las líneas que acabas de agregar.

Pregúntate: ¿este cambio resuelve una sola tarea?, ¿el texto es correcto?, ¿hay algo accidental?

4. Prepara y crea el commit

Pasa README.md al área de staging y escribe:

docs: explicar el inicio del laboratorio

Crea el commit. El staging funciona como la selección de contenido que entrará en la siguiente versión: no tienes que incluir todo lo modificado.

Puedes verificar el resultado desde la terminal:

git status
git show --stat HEAD
git log --oneline --all --graph

Espera un directorio limpio y un commit adicional en docs/inicio-local. La rama main debe seguir en el commit inicial.

5. Integra el resultado

Como este laboratorio es local, integra directamente:

git switch main
git merge --ff-only docs/inicio-local

Observa el gráfico otra vez. main avanzó hasta el commit nuevo. No apareció un commit de merge porque pudo hacerse un avance directo, también llamado fast-forward.

En un equipo, normalmente publicarías la rama y abrirías un pull request antes de integrarla, según las reglas del repositorio.

El hábito que vale la pena conservar

Antes de cada commit, revisa rama, diff y staging. Es una pausa pequeña que permite explicar qué estás guardando y por qué.

GitKraken aporta una vista del historial; el criterio para decidir qué pertenece a un commit sigue siendo tuyo.

Reto: crea docs/objetivo, agrega una sección con el objetivo del laboratorio y repite el flujo. Antes de integrar, explica en voz alta qué cambió y qué rama lo contiene.

¿Qué te cuesta más al empezar con Git: las ramas, el staging o los mensajes de commit?

Stop Reaching for the Edge Runtime

Jesus Manuel Garcia Torres — Sat, 29 Aug 2026 03:31:10 +0000

I want to show you a line of code. You almost certainly have it somewhere:

export const runtime = 'edge'

Go look. I'll wait.

Every time I open someone's Next.js repo, it's there. Usually on a streaming route, sometimes stamped across an entire API folder. And when I ask who put it there, nobody knows. The answer is always some version of "it's faster, right?" or "we needed it for streaming."

Here's the thing: you weren't wrong. In 2022 that was a solid call. But the ground moved under that line, and now it's quietly costing you — Node APIs you can't reach for, libraries that explode at build time, and that one afternoon you lost to "wait, why isn't crypto here?"

So let me walk you through what changed. Not the changelog version — the version that actually rewires how you think about your backend.

First, let's be fair to Edge

I'm not here to tell you past-you was an idiot. Edge Runtime solved two genuinely painful things:

One request, one instance. Every concurrent request needed its own container. Traffic spike? Enjoy your wall of cold starts.
You paid for waiting. Billing was GB-seconds of wall clock. That 900ms your function spent staring at Postgres doing nothing? You paid for it.

Edge dodged both by running a stripped-down V8 isolate instead of a real Node process. Isolates boot in single-digit milliseconds. Beautiful.

The price was Node itself. No fs. No native modules. Half a crypto. A long, miserable tail of npm packages that just don't run.

You took that trade. It was often worth it.

Then Vercel went and fixed the actual problem instead of routing around it. That fix is Fluid Compute, and it's the default now.

The idea that made it click for me

Sit with this one for a second, because everything else falls out of it.

Your backend spends most of its life waiting. Waiting on Postgres. Waiting on Stripe. Waiting four full seconds while an LLM dribbles out tokens one at a time. And during every millisecond of that, the CPU you're paying for is doing absolutely nothing.

Classic serverless shrugs at that. One request owns one instance, start to finish, idle or not.

Fluid looks at the same idle CPU and sees inventory.

A Fluid instance takes multiple concurrent requests. Request 2 shows up while request 1 is blocked on I/O, lands on that same warm instance, and burns CPU that you were throwing in the bin.

Two things follow immediately:

Your cold starts mostly go away. Instances get reused instead of provisioned per request. You get the thing you wanted from Edge — without handing back Node to get it.

Your in-memory state survives. Database pool, cached JWKS, compiled regexes — they persist now, like on a normal server. Flip side, and I'd genuinely watch for this one: module-scope mutable state is now actually shared between concurrent requests. Treat it the way you'd treat state on any long-lived server, because that's what you have now.

If you take one sentence out of this post, take this one: it's a concurrency model change, not a speed trick.

"But we need Edge for streaming"

This is the one I hear most, and it's the expensive one — because it's exactly why Edge ends up on the routes that need Node the most.

Streaming was never an Edge thing. ReadableStream, Server-Sent Events, AI token streaming — all of it runs on the default Node.js runtime. Zero config. Watch:

// app/api/chat/route.ts — no `runtime` export. Node.js. Streams beautifully.
import { streamText } from 'ai'

export async function POST(req: Request) {
  const { messages } = await req.json()

  const result = streamText({
    model: 'anthropic/claude-sonnet-5', // via AI Gateway
    messages,
  })

  return result.toUIMessageStreamResponse()
}

Prefer it raw, no framework? Same story:

export async function GET() {
  const stream = new ReadableStream({
    async start(controller) {
      for (const chunk of await getChunks()) {
        controller.enqueue(new TextEncoder().encode(`data: ${chunk}\n\n`))
      }
      controller.close()
    },
  })

  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      Connection: 'keep-alive',
    },
  })
}

Now flip it around. Your AI route is the worst thing you could put on Edge, not the best. It runs long. It's almost pure I/O wait. It wants SDKs, tracing, a database driver — the whole Node ecosystem.

That's not an edge case for Fluid. That's the exact shape it was built for.

"Edge is cheaper though"

Not anymore, and this is the part I think most people missed: Fluid changed the billing model, not just the runtime.

Vercel Functions now bill on Active CPU time + provisioned memory + invocations. Not GB-seconds of wall clock.

If your function is CPU-bound, this barely moves. If it's I/O-bound — so, most of your functions, and every single AI function you've ever written — the gap between wall clock and active CPU is huge. And you've stopped paying for it.

Then instance reuse compounds it. Three concurrent requests on one warm instance is one block of provisioned memory, not three.

"Middleware has to be Edge"

Two things to untangle here, and they trip people up separately.

Next.js middleware runs full Node.js now. That edge-only constraint is gone. Middleware and Edge Functions are both Vercel Functions under the hood these days.

Routing Middleware is a different product. Framework-agnostic, runs before the cache, works with SvelteKit, Nuxt, Astro, or a pile of static files. It is not Next.js middleware. Keep them separate in your head when you're reading docs, it'll save you an hour.

And while I have you: ISR isn't Next-only either. SvelteKit, Nuxt, and Astro all get it on Vercel.

The limits you're still designing around

This is my favorite part, because I keep finding architecture decisions that are load-bearing on constraints that stopped existing.

If any of these shaped a design of yours, go reopen it.

Two of them trigger a redesign more often than the rest:

5 GB package size. Up from 250 MB. That's a 20× jump, and it means Playwright, Puppeteer, Python data and ML libraries, heavy image processing. If you've got a "we'll need a separate container for this" conversation on the calendar, you might be able to cancel it.

100 MB request bodies. Up from 4.5 MB. Uploads, fat webhook payloads, document intake — straight into a Function. You can stop doing the signed-URL dance you only ever did to dodge a body limit.

And WebSockets work now. So if your reflex is "we'll need Pusher for this one feature," give it a second look first:

import { experimental_upgradeWebSocket } from '@vercel/functions'

export function GET(request: Request) {
  const { socket, response } = experimental_upgradeWebSocket(request)

  socket.addEventListener('message', (event) => {
    socket.send(`echo: ${event.data}`)
  })

  return response
}

Needs Fluid Compute — which, again, you already have. Plain ws and Socket.IO work too.

Do this Monday morning

1. Find your Edge exports. Run this right now, seriously:

grep -rn "runtime = ['\"]edge['\"]" --include="*.ts" --include="*.tsx" .

For every hit, ask yourself one question: what is this buying me? If the answer is "streaming" or "it felt faster" — delete the line. Test it, obviously. But expect it to just work, with more available to it than it had before.

2. Check your Node version. Node 24 is the LTS default. Node 18 is deprecated. If you're pinned to 18, that's a ticket, write it now.

3. Go find your workarounds. Anything you built to dodge a 4.5 MB body, a 250 MB bundle, or a 60-second timeout deserves a fresh look.

4. Try vercel.ts instead of vercel.json. Typed config, real logic, env access:

// vercel.ts
import { routes, type VercelConfig } from '@vercel/config/v1'

export const config: VercelConfig = {
  framework: 'nextjs',
  headers: [
    routes.cacheControl('/static/(.*)', {
      public: true,
      maxAge: '1 week',
      immutable: true,
    }),
  ],
  crons: [{ path: '/api/cleanup', schedule: '0 0 * * *' }],
}

When I'd still use Edge

I'm not telling you it's dead. I still reach for it on genuinely trivial, latency-critical work right at the boundary: a header rewrite, a geo redirect, an A/B bucket assignment, a feature flag lookup. Small, CPU-light, no Node dependencies, runs before anything else touches the request.

That's a narrow band, though. Anything that touches a database, an SDK, a file, or a model? That's Fluid.

Here's the heuristic I'd give you: Edge is a specialist tool for the request boundary. It is not the default for your application code. Somewhere along the way we all flipped that around, and a lot of us are still carrying the flip.

The bit I actually want you to remember

Fluid Compute isn't a Vercel feature to file away. It's a category shift.

We spent years accepting that serverless meant one-request-per-instance, cold starts, and paying for idle time. Then we built elaborate, clever workarounds on top of those assumptions — and got good at maintaining them.

The assumptions changed. The workarounds didn't. A lot of what you're maintaining right now is complexity you're paying for out of habit.

Go delete a line of code. Tell me what breaks.

Written by Jesús García at XpectreLabs. Run that grep and drop what you find in the comments — I'm genuinely curious how many of you have that line sitting on an AI route.