Flujo de trabajo con Git que uso en proyectos reales

En los últimos años he ido afinando un proceso de trabajo con Git que me permite moverme con agilidad en equipos pequeños y medianos, sin perder trazabilidad ni generar sorpresas al desplegar. En este artículo comparto los pasos clave, las convenciones que sigo y algunas herramientas que me ahorran tiempo.

1. Configuración inicial del repositorio

Antes de escribir una sola línea de código, preparo el entorno. Un .gitignore bien pensado evita que archivos temporales o secretos acaben en el historial.

# .gitignore
node_modules/
dist/
.env
.log

También defino una rama main que siempre refleje el código en producción y una rama develop donde integraré las funcionalidades antes de lanzar una versión.

2. Modelo de ramificación (branching)

Mi esquema se basa en los conceptos de Git Flow, pero simplificado para no sobrecargar al equipo:

• main: código listo para producción.
• develop: rama de integración continua.
• feature/: cada nueva funcionalidad.
• release/: preparan la versión final.
• hotfix/: correcciones críticas en producción.

Cuando comienzo una tarea, creo una rama feature a partir de develop:

git checkout develop
git pull origin develop
git checkout -b feature/nueva-funcionalidad

Al terminar, abro un Pull Request (PR) contra develop. Si el PR pasa la revisión y la CI, lo fusiono con --no-ff para preservar la historia:

git checkout develop
git merge --no-ff feature/nueva-funcionalidad
git push origin develop

3. Mensajes de commit claros

Utilizo el formato Conventional Commits para que el historial sea legible tanto para humanos como para herramientas automatizadas. Un ejemplo típico:

git commit -m "feat: añade pantalla de login con validación"

Los prefijos (feat, fix, docs, etc.) facilitan la generación automática de changelogs y la determinación de la versión semántica.

4. Pull Requests y revisión de código

Los PR son el punto de control central. En ellos exijo:

• Al menos un revisor distinto al autor.
• Pasar todas las pruebas de la CI.
• Que el código siga las guías de estilo (ESLint, Prettier).

Si el PR incluye cambios visuales, añado capturas de pantalla o, mejor aún, un enlace a Storybook para que el revisor pueda inspeccionar el componente en aislamiento.

5. Integración continua (CI) ligera

No necesito una cadena de despliegue completa para cada proyecto, pero sí un paso de CI que ejecute:

• Linting (npm run lint).
• Tests unitarios (npm test).
• Build de producción (npm run build).

GitHub Actions es mi opción favorita porque permite definir flujos con YAML directamente en el repositorio y, lo mejor, se ejecuta en cada push o PR.

6. Herramientas auxiliares

Algunas utilidades que he integrado al flujo:

• Git Hooks con husky para evitar commits sin lint ni tests.
• Semantic Release para que la versión y el changelog se actualicen automáticamente a partir de los mensajes de commit.
• GitKraken o la extensión GitLens en VS Code, que facilitan la visualización de la historia y los cambios pendientes.

Estas herramientas no son obligatorias, pero reducen el número de errores humanos y hacen que el proceso sea más predecible.

7. Ciclo de versiones y despliegue

Cuando la rama develop contiene varias funcionalidades listas, creo una rama release:

git checkout develop
git checkout -b release/1.2.0
git push origin release/1.2.0

En la rama release corrijo bugs menores, actualizo la documentación y, una vez satisfecho, la fusiono tanto en main como en develop:

git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0
git push --tags origin main develop

El tag v1.2.0 sirve como punto de referencia para el despliegue en producción.

Conclusión

Este flujo de trabajo con Git combina la claridad de un modelo de ramificación estructurado con la flexibilidad necesaria para proyectos frontend modernos. La clave está en mantener convenciones simples (mensajes de commit, nombres de ramas) y automatizar tanto como sea posible con CI y hooks. Si lo pruebas en tu próximo proyecto, verás cómo la colaboración se vuelve más fluida y el código más estable.