Reglas / lineamientos:
- Commits pequeños y claros.
- No romper otras partes del sistema.
- Probar antes de subir.
- Al hacer un commit nunca mezclar scripts y cambios masivos de escenas.
En un flujo colaborativo con otros programadores:
- Todas las features pasan por Pull Request.
- Todas las ramas deben actualizarse con develop antes de merge.
- Pull Request pequeños.
- La estructura del Pull request debe ser [Tipo PR], por ejemplo “Feat PR”, “Fix PR”, etc.
Consulta la guía de Pull Request aquí:
https://inmersys.atlassian.net/wiki/x/AgBlmQ
Buenas prácticas de commits
| Tipo | ¿Cuándo usarlo? | Ejemplo | Buenas prácticas específicas |
|---|---|---|---|
| Feat | Nueva funcionalidad visible para el usuario | Feat(auth): add password reset flow | Debe representar valor funcional real |
| Fix | Corrección de bugs | Fix(cart): prevent duplicate item insertion | Colocar ID de bug si existe |
| Refactor | Cambio interno sin modificar comportamiento | Refactor(user): extract validation to service | No mezclar con fix ni feat |
| Perf | Mejora rendimiento | Perf(api): reduce response serialization time | Indicar que optimización se hizo |
| Test | Agregar o modificar pruebas | Test(login): add invalid password cases | No mezclar con cambios productivos |
| Docs | Documentación | Docs(readme): update installation steps | Solo documentación |
| Style | Formato, espacios, estructura | Style: apply prettier formating | No debe cambiar lógica |
| Chore | Tareas técnicas sin impacto funcional | Chore: update dependencies | Para mantenimiento del proyecto |
| Builds | Cambios en sistema de build | Build: update gradle config | Relacionado con compilación |
| CI | Cambios de integración continua | CI: add Github Actions workflow | Solo configuración de CI |
| Hotfix | Corrección urgente en producción | Hotfix(payment): fix timeout in production | Directo a la rama creada para la reparación |
| UI | Cambios visuales o UI | UI: adjust button layout spacing | Solo UI, no lógica |
| Scene | Cambios estructurales en escena | Scene(lecel11): adjust spawn positions | No mezclar con scripts grandes |
| Update | Actualización de assets, funciones o funcionalidades | Update: Spawn logic |
- Los commits deben estar en inglés
- 50 - 70 caracteres
- Tiempo verbal presente / imperativo
- Su estructura debe ser: Tipo(scope): Descripción. Ejemplo: Feat(auth): Add password reset flow
- El scope debe ser un módulo, sección o componente afectado
- Si es necesaria una descripción extendida (opcional) tiene que ser para fixes complejos
- Si existe una referencia a un ticket o bug ID debe ser en el footer o al final del mensaje
Recomendaciones antes de un commit:
- ¿El commit es atómico? = Sí
- ¿El mensaje es claro y específico? = Sí
- ¿Incluye archivos innecesarios? = No
- ¿Se puede revertir sin romper algo más? = Sí
Ramas
Las ramas a usar principalmente son:
main → Versión estable (producción / entregas Beta) develop → Integración de features (opcional pero recomendado)
Aunque igual puedes considerar las siguientes:
feature/* → Nuevas funcionalidades fix/* → Bugs refactor/* → Mejoras internas sin cambiar comportamiento hotfix/* → Fixes urgentes en producción
Cualquiera de las ramas anteriores debería crearse desde la rama develop.
Convención de nombres de ramas
Sigue la siguiente estructura al nombrar una nueva rama:
Tipo de rama/Descripción_del_bug/feature/cambio
Ejemplo: feature/vr_grab_system