Flujos de Trabajo de Git para Vibe Coders

Por Qué Git es Innegociable

Las herramientas de codificación con IA hacen cambios grandes rápidamente. En un solo prompt, Claude Code puede reescribir un componente entero, reestructurar un directorio o modificar una docena de archivos. Esa velocidad es increíble — hasta que algo sale mal y quieres volver a cómo estaban las cosas hace cinco minutos.

Sin Git, no puedes. Tu versión funcional anterior se fue, sobrescrita por los cambios de la IA, y tu única opción es intentar deshacer todo manualmente (buena suerte) o empezar de nuevo.

Con Git, puedes revertir a cualquier estado previo de tu proyecto en segundos. Es tu botón de deshacer, tu red de seguridad y tu máquina del tiempo. Te permite experimentar sin miedo porque siempre tienes una versión funcional a la cual volver.

Si solo te llevas una cosa de esta lección, que sea esto: haz commits temprano, haz commits a menudo. Cada commit es un punto de guardado. Cuantos más puntos de guardado tengas, menos puedes perder.

Git también es la forma en que los equipos profesionales de software colaboran. Si estás construyendo algo con otros, o si alguna vez quieres compartir tu código en GitHub, Git es la herramienta que lo hace posible. Aprenderlo ahora rinde dividendos por el resto de tu carrera como constructor.

Conceptos Básicos de Git para No-Desarrolladores

Si nunca has usado Git, aquí están los conceptos y comandos esenciales. No te preocupes por memorizarlos — los aprenderás a través de la repetición, y Claude Code puede manejar la mayoría de las operaciones de Git por ti. Pero entender lo que sucede internamente te convierte en un mejor vibe coder.

git init — Comenzar a Rastrear un Proyecto

git init

Este comando convierte una carpeta regular en un proyecto rastreado por Git. Crea un directorio oculto .git que almacena todo tu historial de versiones. Solo necesitas ejecutarlo una vez por proyecto. Si clonaste un proyecto de GitHub o lo creaste con create-next-app, Git ya está inicializado.

git add — Preparar Tus Cambios

git add app/page.tsx
git add .

Antes de poder guardar una instantánea (commit), necesitas decirle a Git qué cambios incluir. Esto se llama "staging" (preparación). Piensa en ello como poner artículos en una cinta transportadora antes de que vayan al almacén.

git add app/page.tsx prepara un archivo específico. git add . prepara todo lo que cambió. Cuando estás empezando, git add . está bien. A medida que te sientas más cómodo, preparar archivos específicos te da más control sobre lo que va en cada commit.

El área de staging es una zona de espera entre tus archivos de trabajo y el historial permanente. Existe para que puedas revisar y organizar tus cambios antes de hacer commit.

git commit -m "message" — Guardar una Instantánea

git commit -m "add contact form with email validation"

Un commit es una instantánea permanente de tu proyecto en un punto específico del tiempo. Registra cada cambio preparado junto con un mensaje describiendo qué cambió. Siempre puedes volver a cualquier commit, sin importar cuánto cambie el proyecto después.

La bandera -m te permite escribir el mensaje del commit en línea. El mensaje debe describir qué cambió y opcionalmente por qué. Buenos mensajes te ahorran tiempo cuando necesitas encontrar una versión específica más tarde.

git status — Ver Qué Cambió

git status

Esto te muestra qué se ha modificado, qué está preparado y qué no está rastreado. Es tu panel de control para entender el estado actual de tu proyecto. Ejecútalo seguido — antes de hacer commit, después de hacer cambios, siempre que no estés seguro del estado de las cosas.

La salida te dice:

• Changes to be committed — preparados y listos para commit
• Changes not staged for commit — modificados pero aún no preparados
• Untracked files — archivos nuevos que Git no ha visto antes

git log --oneline — Ver Tu Historial

git log --oneline

Esto muestra una lista compacta de tus commits, del más reciente al más antiguo. Cada línea muestra un hash de commit corto (un identificador único) y el mensaje del commit.

a3f2c1d add contact form with email validation
b7e4a89 set up homepage hero section
c1d9f32 initial project setup

Esta es la línea de tiempo de tu proyecto. Cuando necesites volver a una versión específica, estos mensajes te ayudan a encontrar la correcta.

git diff — Ver Qué Cambió en Detalle

git diff

Esto muestra las líneas exactas que cambiaron en tus archivos. Las líneas agregadas se muestran en verde con un prefijo +, las eliminadas en rojo con un prefijo -. Es la vista más detallada de en qué has estado trabajando.

git diff --staged

Esto muestra lo que está actualmente preparado y a punto de ser incluido en el commit. Siempre revisa esto antes de hacer commit para asegurarte de que no estás incluyendo cambios no deseados.

El Patrón de Checkpoint

El patrón de checkpoint es el flujo de trabajo más importante para el vibe coding. La idea es simple: haz commit antes de cada cambio grande con IA.

Piensa en los commits como puntos de guardado en un videojuego. Antes de entrar a la pelea contra el jefe (pedirle a la IA que haga un cambio importante), guardas tu progreso. Si la pelea sale mal, cargas desde el punto de guardado.

Así funciona en la práctica:

# Acabas de terminar la homepage y se ve genial
git add .
git commit -m "feat: complete homepage with hero, features, and CTA sections"

# Ahora quieres que la IA agregue autenticación — un cambio grande y arriesgado
# Antes de pedirle a la IA, ya tienes un punto de guardado

# La IA hace los cambios... pero la autenticación rompió el layout
# No hay problema — puedes ver qué cambió:
git diff

# Si quieres deshacer todo lo que la IA acaba de hacer:
git checkout -- .

# Estás de vuelta en tu homepage funcional, listo para intentar de nuevo

Nombrar Checkpoints de Manera Significativa

Buenos nombres de checkpoint facilitan encontrar el punto de guardado correcto más tarde. Aquí hay una convención de nombres que funciona bien:

# Usa prefijos de conventional commits
git commit -m "feat: add user registration form"
git commit -m "fix: resolve mobile nav not closing on click"
git commit -m "refactor: extract header into separate component"
git commit -m "style: update pricing cards to match new design"
git commit -m "chore: update dependencies to latest versions"

El prefijo te dice qué tipo de cambio fue. La descripción te dice qué cambió específicamente. Juntos, crean un historial que realmente puedes navegar.

Malos nombres de checkpoint:

"update"
"fix stuff"
"changes"
"wip"
"asdf"

Buenos nombres de checkpoint:

"feat: add Stripe checkout integration"
"fix: prevent duplicate form submissions"
"refactor: move auth logic to shared middleware"
"style: redesign dashboard sidebar for mobile"

Cuando estés recorriendo git log tratando de encontrar el commit donde todo aún funcionaba, te agradecerás a ti mismo por escribir mensajes claros.

Branching para Experimentos

A veces quieres probar algo arriesgado sin ninguna posibilidad de arruinar tu código funcional. Para eso son las ramas (branches).

Una rama es una versión paralela de tu proyecto. Puedes hacer cualquier cambio que quieras en una rama sin afectar la versión principal. Si el experimento funciona, lo fusionas de vuelta. Si falla, eliminas la rama. Tu código principal nunca fue tocado.

El Flujo Básico de Ramas

# Estás en main, todo funciona
# Quieres probar agregar una funcionalidad de dark mode

# Crea y cambia a una nueva rama
git checkout -b feature/dark-mode

# Ahora estás en la rama feature/dark-mode
# Pide a la IA que implemente dark mode
# Prueba, itera, hazlo funcionar

# Si funciona — fusiona de vuelta a main
git checkout main
git merge feature/dark-mode

# Si no funciona — elimina la rama
git checkout main
git branch -d feature/dark-mode
# Todos los cambios de dark mode se fueron, main no fue tocado

Cuándo Usar Ramas

Usa ramas cuando:

• Estás probando algo experimental. "Veamos si podemos reestructurar completamente el modelo de datos" es un experimento que merece una rama.
• Estás haciendo cambios que podrías querer descartar. Si hay una posibilidad real de que no conservarás los cambios, hazlos en una rama.
• Estás trabajando en múltiples cosas a la vez. Puedes tener una rama feature/dark-mode y una rama fix/login-bug simultáneamente.
• Quieres una revisión limpia. Las ramas facilitan ver todos los cambios de una sola funcionalidad agrupados, separados de otro trabajo.

Para cambios pequeños y de bajo riesgo — corregir un typo, ajustar el padding, cambiar un color — crear una rama es excesivo. Solo haz commit en main. Reserva las ramas para cambios que abarcan múltiples archivos o involucran riesgo significativo.

Recuperarse de Errores de la IA

La IA a veces producirá código que rompe cosas. Eso es normal, y Git te da varias formas de recuperarte. Aquí están las herramientas, ordenadas de la más suave a la más agresiva.

Deshacer Todos los Cambios No Commiteados

git checkout -- .

Esto descarta todos los cambios desde tu último commit. Cada archivo modificado vuelve a como estaba. Este es tu botón de "no, deshacer todo." Úsalo cuando la IA hizo cambios completamente incorrectos y quieres empezar de nuevo.

Advertencia: Esto elimina permanentemente todos los cambios no commiteados. Asegúrate de que realmente quieres perderlos.

Deshacer el Último Commit (Conservar Cambios)

git reset HEAD~1

Esto deshace el último commit pero conserva todos los cambios de archivos en tu directorio de trabajo. Los cambios ya no están commiteados, pero siguen ahí para que los modifiques o hagas commit selectivamente.

Usa esto cuando hiciste commit demasiado rápido y quieres hacer ajustes antes de volver a commitear.

Archivar Cambios Temporalmente

# Guarda tus cambios actuales para después
git stash

# Tu directorio de trabajo ahora está limpio (de vuelta al último commit)
# Haz lo que necesites hacer...

# Trae tus cambios de vuelta
git stash pop

El stashing es útil cuando estás en medio de algo y necesitas cambiar de contexto rápidamente. Quizás estás trabajando en una funcionalidad cuando descubres un bug que necesita corrección inmediata. Guarda (stash) tu trabajo de funcionalidad, corrige el bug, haz commit de la corrección, luego recupera tu stash para continuar donde lo dejaste.

Cuándo Usar Cada Método de Recuperación

Aquí hay una guía rápida de decisión:

"La IA hizo cambios y aún no los he commiteado. Quiero deshacerlo todo." Usa git checkout -- . para descartar todos los cambios no commiteados.

"Commiteé los cambios de la IA pero están mal. Quiero probar un enfoque diferente." Usa git reset HEAD~1 para deshacer el commit pero conservar los archivos, luego usa git checkout -- . para descartar los cambios completamente.

"Estoy en medio del trabajo en la funcionalidad A pero necesito corregir rápidamente el bug B." Usa git stash para archivar la funcionalidad A, corrige y commitea el bug B, luego git stash pop para retomar la funcionalidad A.

"Quiero ver una versión anterior de un archivo específico." Usa git show HEAD~3:app/page.tsx para ver cómo se veía ese archivo hace 3 commits, sin cambiar nada en tu directorio actual.

"Todo está roto y solo quiero volver a un estado que funcione." Usa git log --oneline para encontrar el hash del buen commit, luego git reset --hard <commit-hash>. Advertencia: esto descarta permanentemente todos los cambios después de ese commit.

El Flujo de Trabajo de PR con IA

Un Pull Request (PR) es una forma formal de proponer cambios a un proyecto. Incluso si trabajas solo, los PRs son valiosos porque crean un punto de revisión antes de que los cambios se fusionen en tu rama principal.

Aquí está el flujo de trabajo:

# 1. Crea una rama para tu funcionalidad
git checkout -b feature/user-profile

# 2. Haz cambios con asistencia de IA
# ... prompt, itera, prueba ...

# 3. Commitea tus cambios
git add .
git commit -m "feat: add user profile page with avatar upload"

# 4. Sube la rama a GitHub
git push -u origin feature/user-profile

# 5. Crea un Pull Request
gh pr create --title "Add user profile page" --body "Adds a profile page where users can view and edit their information, including avatar upload."

# 6. Revisa el PR (o que alguien más lo revise)
# 7. Fusiona cuando esté listo
gh pr merge

Por Qué Importan los PRs

Para proyectos individuales: Los PRs crean un punto natural de revisión. En lugar de hacer commit directamente a main, puedes revisar todos los cambios juntos, ejecutar tests y asegurarte de que todo se ve bien antes de fusionar. Agrega un punto de control entre "la IA generó esto" y "esto está en producción."

Para proyectos en equipo: Los PRs son la forma en que los equipos colaboran. Cada persona trabaja en su propia rama, crea un PR, y el equipo revisa los cambios antes de fusionarlos. Esto previene que los cambios de una persona rompan el trabajo de otra.

Para tu portafolio: Un perfil de GitHub con PRs bien organizados muestra que sigues prácticas de desarrollo profesionales. Demuestra que no solo escribes código — lo revisas, lo organizas y lo gestionas.

Convenciones de Mensajes de Commit

Conventional Commits es un formato estándar para mensajes de commit que hace tu historial fácil de leer y navegar. El formato es:

type: description

Estos son los tipos y cuándo usar cada uno:

feat: — Una Nueva Funcionalidad

git commit -m "feat: add email notification system"
git commit -m "feat: implement dark mode toggle"
git commit -m "feat: add CSV export to dashboard"

Usa feat: cuando agregas algo que no existía antes. Una nueva página, un nuevo componente, un nuevo endpoint de API, una nueva capacidad.

fix: — Una Corrección de Bug

git commit -m "fix: resolve login form not submitting on mobile Safari"
git commit -m "fix: correct pricing calculation for annual plans"
git commit -m "fix: prevent duplicate webhook processing"

Usa fix: cuando corriges algo que estaba roto. La cosa existía antes pero no estaba funcionando correctamente.

refactor: — Reestructuración de Código

git commit -m "refactor: extract auth logic into shared middleware"
git commit -m "refactor: replace class components with functional components"
git commit -m "refactor: reorganize utility functions by domain"

Usa refactor: cuando cambias cómo el código está organizado o estructurado sin cambiar lo que hace. La app se comporta exactamente igual, pero el código está más limpio.

style: — Cambios Visuales

git commit -m "style: update button colors to match new brand guidelines"
git commit -m "style: improve mobile spacing on pricing page"
git commit -m "style: add hover animations to feature cards"

Usa style: para cambios puramente visuales — actualizaciones de CSS, ajustes de layout, retoques de diseño. Sin cambios de comportamiento.

docs: — Documentación

git commit -m "docs: add API endpoint documentation"
git commit -m "docs: update README with setup instructions"
git commit -m "docs: add inline comments to auth flow"

test: — Tests

git commit -m "test: add unit tests for pricing calculation"
git commit -m "test: add integration tests for checkout flow"

chore: — Mantenimiento

git commit -m "chore: update dependencies to latest versions"
git commit -m "chore: configure CI/CD pipeline"
git commit -m "chore: add pre-commit hooks for linting"

Usa chore: para tareas que no cambian el código de la aplicación — actualizar configuraciones, gestionar dependencias, configurar herramientas.

Por Qué Importa la Consistencia

Cuando tu historial de commits sigue un formato consistente, puedes:

• Escanear rápidamente todas las correcciones de bugs: busca commits con fix:
• Encontrar cuándo se agregó una funcionalidad: busca commits con feat:
• Generar changelogs automáticamente a partir de mensajes de commit
• Entender la evolución del proyecto de un vistazo

Mensajes inconsistentes como "stuff," "fixed it," y "more changes" no te dicen nada. Mensajes consistentes crean una narrativa legible del desarrollo de tu proyecto.

Esenciales de .gitignore

Tu archivo .gitignore le dice a Git qué archivos y directorios ignorar — no serán rastreados, commiteados ni subidos a GitHub. Esto es crítico para mantener tu repositorio limpio y seguro.

Aquí hay un .gitignore sólido para la mayoría de proyectos JavaScript/TypeScript:

# Dependencies
node_modules/

# Environment variables (contains secrets!)
.env
.env.local
.env.production

# Build output
.next/
dist/
build/
out/

# OS files
.DS_Store
Thumbs.db

# IDE files
.vscode/
.idea/

# Debug logs
npm-debug.log*
yarn-debug.log*

# TypeScript cache
*.tsbuildinfo

# Test coverage
coverage/

Por Qué Estos Archivos No Deben Ser Rastreados

node_modules/ — Este directorio puede contener decenas de miles de archivos y cientos de megabytes. Es completamente reproducible desde package.json ejecutando npm install. Rastrearlo haría tu repositorio más pesado y ralentizaría cada operación de Git.

.env y .env.local — Estos archivos contienen API keys, contraseñas de base de datos y otros secretos. Si los commiteas, cualquiera que pueda ver tu repositorio puede ver tus secretos. Este es uno de los errores de seguridad más comunes que cometen los desarrolladores. Nunca commitees archivos de entorno.

.next/ y dist/ — Estos son artefactos de build generados a partir de tu código fuente. Son reproducibles y generalmente grandes. Rastrea el código fuente, no la salida.

.DS_Store y Thumbs.db — Estos son archivos de metadatos del sistema operativo que no tienen relevancia para tu proyecto. Solo agregan ruido.

Si accidentalmente commiteaste un archivo que debería ser ignorado, agregarlo a .gitignore no lo eliminará del historial. Necesitas eliminarlo explícitamente:

git rm --cached .env
git commit -m "chore: remove accidentally committed .env file"

Integración de Git + Claude Code

Una de las grandes ventajas de Claude Code es que entiende Git de forma nativa. Puedes pedirle que realice operaciones de Git usando lenguaje natural, y ejecutará los comandos apropiados.

Ejemplos de Prompts Relacionados con Git

Crear commits:

Commit the current changes with a descriptive message following
conventional commits format

Claude Code revisará qué cambió, creará un mensaje de commit apropiado y creará el commit.

Crear ramas:

Create a new branch called feature/user-settings and switch to it

Revisar cambios:

Show me what changed since the last commit and explain each change

Esto es increíblemente poderoso — Claude Code no solo puede mostrarte el diff sino explicar qué hace cada cambio en lenguaje sencillo.

Crear Pull Requests:

Push this branch and create a PR with a summary of all the changes
we made in this session

Claude Code subirá la rama, luego usará el GitHub CLI para crear un PR con una descripción bien escrita.

Recuperarse de errores:

The last set of changes broke the login page. Revert everything
back to the previous commit.

Revisar historial:

Show me the last 10 commits and tell me which one added the payment feature

No necesitas memorizar comandos de Git. Entender los conceptos es suficiente — Claude Code puede traducir tus intenciones a los comandos correctos. Pero saber qué es posible te ayuda a pedir las cosas correctas.

Lo Que Sigue

Ahora tienes una red de seguridad. Con Git en tu flujo de trabajo, puedes pedirle a la IA que haga cambios audaces sabiendo que siempre puedes deshacerlos. Puedes experimentar en ramas, recuperarte de errores y mantener un historial limpio de la evolución de tu proyecto.

Pero ¿qué pasa cuando los cambios de la IA no funcionan del todo? ¿Cuando el build falla, el estilo se ve mal, o una funcionalidad se comporta inesperadamente? En la próxima lección, dominaremos la iteración y depuración con IA — el ciclo de retroalimentación que convierte "casi correcto" en "exactamente correcto." Aprenderás cómo dar feedback efectivo, leer mensajes de error y saber cuándo iterar versus cuándo empezar de nuevo.