Flujo de trabajo Git para TypeScript: cómo no volverse loco con el código tipado

Flujo de trabajo Git para TypeScript: cómo dejar de temer los conflictos de fusión

Si alguna vez has intentado fusionar dos ramas, donde una modificaba la interfaz User y la otra añadía un nuevo tipo en el mismo módulo, sabes lo que es una crisis existencial de desarrollador. TypeScript nos da un potente sistema de tipos, pero sin un flujo de trabajo Git adecuado, ese poder se convierte en un dolor de cabeza.

En este artículo, analizaremos el flujo de trabajo Git óptimo para proyectos TypeScript, desde la configuración de ramas hasta la verificación automática de tipos en cada commit. Sin rodeos, solo lo que realmente funciona en producción.

¿Por qué TypeScript requiere un enfoque especial para Git?

TypeScript no es solo "JavaScript con tipos". Es un lenguaje donde cada cambio puede afectar a decenas de archivos a través de interface, type y genéricos. Una modificación incorrecta en un tipo base y todo el proyecto deja de compilar.

Por lo tanto, un flujo de trabajo Git estándar para TypeScript debe incluir:

\n
• Verificación obligatoria de tipos antes del commit
\n
• Un linter que impida commitear código sin formato
\n
• Una estrategia de ramificación clara para que los conflictos de fusión no rompan los tipos
\n
• CI/CD que lo verifique todo en el servidor
\n

Analicemos cada punto en orden.

1. Elegir una estrategia de ramificación: ¿Git Flow o Trunk-based?

Para proyectos TypeScript, recomiendo el desarrollo Trunk-based con ramas de corta duración. ¿Por qué? Porque el código TypeScript es, esencialmente, código "en bruto" que necesita ser verificado y desplegado rápidamente. Las ramas largas hacen que los tipos se "desalineen".

Estructura básica de ramas

main        — versión estable, siempre lista para desplegar\ndevelop     — rama principal de desarrollo\nfeature/*   — nuevas funcionalidades (viven 1-2 días)\nfix/*       — correcciones de errores\nrelease/*   — preparación de lanzamiento (opcional)\n

Ejemplo para un proyecto TypeScript:

git checkout -b feature/add-user-validation\n# trabajamos...\ngit commit -m "feat: add email validation for User type"\ngit push origin feature/add-user-validation\n# creamos PR → fusionamos en develop\n

Importante: nunca hagas rebase en main si el proyecto tiene tipos compartidos. Usa merge: conserva el historial y no rompe dependencias.

2. Git Hooks: protección contra tontos (y contra ti mismo)

El escenario más común: olvidaste ejecutar tsc, hiciste commit, hiciste push y el CI falló. Para evitarlo, configuramos pre-commit hooks.

Instalación de Husky + lint-staged

Husky es una herramienta para gestionar Git hooks. lint-staged ejecuta comandos solo en los archivos modificados.

npm install --save-dev husky lint-staged\nnpx husky init\n

Creamos el archivo .husky/pre-commit:

#!/usr/bin/env sh\n. "$(dirname -- "$0")/_/husky.sh"\n\nnpx lint-staged\n

En package.json añadimos:

{\n  "lint-staged": {\n    "*.ts": [\n      "eslint --fix",\n      "prettier --write",\n      "tsc --noEmit"\n    ]\n  }\n}\n

Ahora, antes de cada commit:

\n
1. Se ejecuta ESLint con corrección automática
\n
2. Se formatea el código con Prettier
\n
3. Se verifica la compilación de TypeScript (tsc --noEmit)
\n

Si algún paso falla, el commit no se realiza. Es duro, pero efectivo.

3. Mensajes de commit correctos: conventional commits

Los proyectos TypeScript se benefician de los conventional commits porque:

\n
• Se genera un changelog automáticamente
\n
• Es fácil entender qué cambios rompen los tipos
\n
• Se puede activar el CI solo para commits específicos
\n

Ejemplos:

feat: add UserRole enum and validation\nfix: c