Branches y versionado
Naming conventions y workflow para el versionado de código en proyectos con fees.
🌿 Nomenclatura de branches
Para proyectos con fees
Al trabajar en proyectos facturables, crear branches con el número de ticket correspondiente:
Formato: [tipo]/[número-ticket]
Tipos de branch:
feature/- Nueva funcionalidadfix/- Bug fixeshotfix/- Fixes urgentesrefactor/- Refactoring de códigodocs/- Documentación
Ejemplos de nomenclatura
🔄 Workflow de desarrollo
Proceso estándar
Convenciones de commits
Formato: [tipo]: [descripción breve]
Tipos principales:
feat:- Nueva funcionalidadfix:- Bug fixrefactor:- Refactoring sin cambio de funcionalidadstyle:- Cambios de styling/formatodocs:- Documentacióntest:- Testschore:- Tareas de mantenimiento
Ejemplos:
🔗 Linking tickets y código
En commits
Referenciar ticket en commits:
En Pull Requests
Template de PR:
🔄 Hotfixes y rollbacks
Proceso de hotfix
Rollback strategy
🎯 Best practices
Para developers
- 🔗 Always link tickets: Cada branch debe corresponder a un ticket
- 📝 Descriptive commits: Commits claros y específicos
- 🔍 Small PRs: Pull requests focalizados y reviewables
- 🧹 Clean history: Rebase/squash cuando sea apropiado
- 📋 Update tickets: Mantener tickets actualizados con progress
Para code reviewers
- ⚡ Timely reviews: Responder dentro de 24h
- 🎯 Focus on impact: Priorizar issues que afectan funcionalidad
- 📚 Knowledge sharing: Usar reviews para enseñar/aprender
- ✅ Test functionality: No solo review código, probar funcionalidad
- 📖 Check documentation: Validar que documentación esté actualizada
🌿 Un buen sistema de branching y versionado facilita la colaboración y reduce los riesgos en cada deploy.