Flujo de trabajo con Git

Plantilla de ejemplo. Ajusta el flujo (trunk-based, GitFlow, etc.) a tu equipo.

Mensajes de commit (Conventional Commits)

Formato: tipo(ámbito opcional): descripción en imperativo


feat(checkout): añade soporte para Checkout Pro
fix(pagos): corrige cálculo de impuestos en ciclos per_use
docs(readme): documenta pasos de deploy en Vercel
refactor(api): simplifica el cliente de Supabase

Tipos más usados:

Tipo	Cuándo usarlo
`feat`	Nueva funcionalidad
`fix`	Corrección de un bug
`docs`	Solo cambios de documentación
`refactor`	Cambio interno sin alterar comportamiento
`chore`	Mantenimiento (deps, configs, tooling)
`test`	Añadir o corregir pruebas

Pull Requests

Mantén los PR pequeños y enfocados: más fáciles de revisar y de revertir.
Describe el qué y el porqué, no solo el cómo.
Enlaza el issue o ticket relacionado.
Requiere al menos una aprobación antes de hacer merge.

Flujo recomendado

Crea una rama


git checkout -b feat/mi-funcionalidad

Haz commits pequeños y descriptivos


git commit -m "feat(modulo): describe el cambio"

Abre el Pull Request

Empuja la rama y abre el PR contra main. CI ejecutará linting, tipos y pruebas.

Merge tras aprobación

Una vez aprobado y con CI en verde, haz squash & merge. Vercel desplegará automáticamente.

Nunca hagas push --force sobre main. Para reescribir historial, hazlo solo en tu rama y avisa al equipo.